From nobody Sun Jan 1 09:15:28 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 228871293FE for ; Sun, 1 Jan 2017 09:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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=-3.1, 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 n54SER34pdIK for ; Sun, 1 Jan 2017 09:15:23 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B181A1200A0 for ; Sun, 1 Jan 2017 09:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55256; q=dns/txt; s=iport; t=1483290922; x=1484500522; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7V0lzfambckvxy0O8x3xR2JmbEiLRyyX/xLrXuHz9HY=; b=T3XYWc9SJsGiAcCk4041Uz3OnUs8ZRjefI+7hMgQGbepXq3DzaIE6usj nbE+HDlemdGC4bBLsNyYZAPyzhZyEMf3J7KxtJdK7gFQomlEaTjniK8Cc Up4uA17Sfo/PTWh5MKWZ8rbamNvKC5vTO6CadeUmVBFZdrFlo3uifi28m I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQA9OGlY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnE5DQEBAQEBH1+BDAeNUJRDlRuCCC6FdAKBXz8UAQIBAQEBAQE?= =?us-ascii?q?BYiiEaAEBAQQaE1wCAQgRBAEBIQEGBzIUCQgCBAESCBOIVQ6xUYo3AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWGRYRhhHyFKwWVCYV0AYZTgxKHT4F+hQiDSoYOh36?= =?us-ascii?q?GMIQOAR84SmCEERyBXnIBhzCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,432,1477958400"; d="scan'208,217";a="189152526" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jan 2017 17:15:19 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v01HFJAL027369 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 1 Jan 2017 17:15:19 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 1 Jan 2017 11:15:18 -0600 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, 1 Jan 2017 11:15:18 -0600 From: "Les Ginsberg (ginsberg)" To: "Aissaoui, Mustapha (Nokia - CA)" , "spring@ietf.org" Thread-Topic: SID Conflict Resolution: A Simpler Proposal Thread-Index: AdJOibcaOvA8JiDrT2eiOTpEk40qzwDAodWgAC/MMoAChMj6cAAKwMEwACcyuzAByc3HIA== Date: Sun, 1 Jan 2017 17:15:18 +0000 Message-ID: <41bfb2542a984dc29ef0b99fecf06de2@XCH-ALN-001.cisco.com> References: <84fe7b43d5054712abf09b274bc3c471@XCH-ALN-001.cisco.com> <4A79394211F1AF4EB57D998426C9340DD4AFFBBF@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340DD4B100A7@US70UWXCHMBA01.zam.alcatel-lucent.com> <63a79609cc964132a1f67cb75da98cf7@XCH-ALN-001.cisco.com> <4A79394211F1AF4EB57D998426C9340DD4B115EF@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340DD4B115EF@US70UWXCHMBA01.zam.alcatel-lucent.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.117.188] Content-Type: multipart/alternative; boundary="_000_41bfb2542a984dc29ef0b99fecf06de2XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jan 2017 17:15:27 -0000 --_000_41bfb2542a984dc29ef0b99fecf06de2XCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mustapha - Some responses inline, but I emphasize again that the most important issue = being discussed at the moment is what to do when conflicts are detected. Th= ere are two proposals: 1)Do not use the SIDs which are in conflict ("Ignore") 2)Use some conflict resolution algorithm to choose how to use the conflicti= ng SIDs ("Ignore overlap only") I would encourage you and everyone else to comment on that. If we choose #2 above then the specific preference rule (currently defined = in Section 3.3.4 of the draft) can be reviewed - but not much point in doin= g so until we decide whether we are going to use a preference rule at all. From: Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissaoui@nokia.com] Sent: Friday, December 23, 2016 6:59 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Hi Les, I made some follow-up inline. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Thursday, December 22, 2016 2:37 PM To: Aissaoui, Mustapha (Nokia - CA) ; spring@i= etf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Mustapha - From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Nokia - CA) Sent: Thursday, December 22, 2016 8:10 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal Hi Les, I read slides 17-21 of the document you referenced below and I have the fol= lowing comments: 1. Page 17, "Order Matters - Prefix vs SID Conflict". When you perform resolution on a per prefix basis, prefix conflicts are na= turally processed first followed by SID conflicts across different prefixes= . So the ordering issue described is only specific if you decided to resolv= e conflicting SID entries outside of the natural prefix resolution by a rou= ter. [Les:] What may seem "natural" to you might not to someone else. I don't ca= re to debate that point. What is being illustrated here is that in order to= provide a normative specification that - if followed - guarantees interope= rability we have to specify the order in which conflicts are processed othe= rwise different results may be obtained. MA> I agree on the intent of specifying a procedure which achieves interope= rability. However, it seems to me this draft is ignoring the fact that rout= ers do per-prefix resolution and is trying to perform the SID resolution ou= tside of it. [Les2:] Section 3.2 of the draft details the types of conflicts which may o= ccur. These include: 1)Prefix conflicts - different SIDs assigned to the same prefix 2)SID conflicts - multiple prefixes associated with the same SID The term "pre-prefix resolution" suggests to me that you think all we have = to do is find all the SID advertisements associated with a given prefix in = order to determine whether we have a conflict or not. But that only finds "= prefix conflicts" - it does not find SID conflicts - and both have to be de= alt with. If you mean something else please clarify. 2. Page 18, "Order Matters: Derived vs non-derived- prefix conflict". It seems to me this issue is an artifact of the specific algorithm used to = resolve conflicts. Because the algorithm uses parameters such as "Range (st= art w smallest)" then obviously derived SRMS entries will lend a different = result than original SRMS entries. With the pre-prefix resolution, the only information kept from the original= SRMS entry is the preference and the advertising or owner router. Anything= else is not used. It seems to me a simple algorithm based on preference fi= rst then followed by some rule on selecting the advertising router if confl= icts exist within the same preference would work. [Les:] You have implemented things in a certain way. Someone else might cho= ose to implement in a different way. A normative specification does not (an= d should not) constrain an implementation. What is being illustrated here i= s that if the implementation does not retain the underived entry (in whatev= er internal form it chooses) different results will be obtained because the= preference algorithm depends on comparing the underived ranges. MA> I do not believe this is about implementation. It is about what routers= do and that is resolution per prefix. It does not matter how the prefix SI= D information is advertised, individually or part of an SRMS entry, at the = end it is associated with a prefix. 3. Finally, there is something which has not been addressed in the slid= es. There is still a possibility of conflicting entries among SIDs advertis= ed using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or = OSPF Extended Prefix TLV). A simple rule selecting the advertising router s= hould also work fine here. [Les:] No - source of an advertisement has been quite deliberately excluded= from the preference algorithm. With redistribution/route leaking the sourc= e of an advertisement may appear to be different on different routers- this= would result in different results on different routers. MA> The following RFC is specifying an optional attribute (the IPv4/IPv6 So= urce Router ID TLV) to encode the original advertising router of a prefix. = This can be used to perform a simple selection algorithm: https://tools.ietf.org/html/rfc7794#section-2.2 Otherwise, what is your proposal for this point (3)? I could not find it ad= dressed in the current version of the draft. [Les2:] The proposal is NOT to use the source of an advertisement as an inp= ut to conflict resolution. RFC 7794 only addresses the issue for IS-IS and even then only for SIDs lea= rned via prefix reachability advertisements. Use of source still has consis= tency issues for SRMS advertisements, OSPF, and cases which involve multipl= e protocol instances. This choice has been consciously made and is in part based on our experienc= e with existing implementations. That said, this issue is only relevant if you believe it is necessary/desir= able to use a preference rule to make a choice when a conflict exists. The proponents of "Ignore" don't want to do this - we want to NOT use SIDs = which are in conflict. We believe this is less likely to lead to interopera= bility problems and is less likely to have undesirable side effects. It als= o prioritizes detection and reporting of conflicts. Les Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, December 09, 2016 1:49 PM To: Aissaoui, Mustapha (Nokia - CA) >; spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Mustapha - From: Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissaoui@nokia.com] Sent: Friday, December 09, 2016 7:44 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal I have a couple of comments on the below proposal. 1. Regarding the SRMS Preference Sub-TLV in section 3.1 of the draft. I= n many cases, a configuration on the resolving router can assign a preferen= ce to each SRMS in case there is no advertisement of this sub-TLV or to ove= rride an advertised value. I propose that this option be allowed. Here is a= proposed update to the relevant paragraph: " Advertisement of a preference value is optional. Nodes which do= not advertise a preference value are assigned a preference value of 1= 28. A resolving router can override the default or the advertised va= lue by local policy. " [Les:] In order to get consistent conflict resolution on all nodes in the n= etwork, it is necessary that they all have the same database - which includ= es the preference value. If you allow local policy to modify the preference= you no longer have consistent databases on all nodes and we can no longer = guarantee consistent conflict resolution. So your proposal is not viable IM= O. 2. I am trying to understand the concept of sorting SRMS entries which = have different prefixes and different range sizes. Since a SID advertised in a prefix SID sub-TLV within a Prefix TLV (IS-IS I= P Reach TLV or OSPF Extended Prefix TLV) has higher priority over a SID for= the same prefix advertised from a SRMS, then you have to add to the below = sorting an entry for each individual prefix which advertised a prefix SID s= ub-TLV within a prefix TLV. At this point, the concept of an entry with multiple prefixes is moot and y= ou may as well just sort on a per prefix basis which is the most natural th= ing to do given that the prefix resolution and then the SID resolution are = performed on a per prefix basis. SID conflicts can be resolved on a per pre= fix basis using the below proposed preference algorithm without having to i= gnore SID values for unrelated prefixes just because it happens that they w= ere advertised in the same SRMS entry. [Les:] The simpler proposal does not require sorting on anything other than= preference. After that, you can process entries in any order you want and = you will get the same answer. With "Ignore Overlap Only" one of the issues with trying to use the non-con= flicting portions of a mapping entry which has a range > 1 is that the orde= r in which you process entries influences the result. Please see slides 17 = - 20 from the IETF97 presentation: https://www.ietf.org/proceedings/97/slid= es/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pp= tx for some simple examples of this. Les Regards, Mustapha. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Sunday, December 04, 2016 7:04 PM To: spring@ietf.org Subject: [spring] SID Conflict Resolution: A Simpler Proposal When the problem addressed by draft-ietf-spring-conflict-resolution was fir= st presented at IETF 94, the authors defined the following priorities: 1)Detect the problem 2)Report the problem This alerts the network operator to the existence of a conflict so that the configuration error can be corrected. 3)Define consistent behavior This avoids mis-forwarding while the conflict exists. 4)Don't overengineer the solution Given that it is impossible to know which of the conflicting entries is the correct one, we should apply a simple algorithm to resolve the confl= ict. 5)Agree on the resolution behavior The resolution behavior was deliberately the last point because it was considered the least important. Input was received over the past year which emphasized the importance of trying to "maximize forwarding" in the presence of conflicts. Subsequent revisions of the draft have tried to address this concern. However the auth= ors have repeatedly stressed that the solution being proposed ("ignore overlap only") was more complex than other offered alternatives an= d would be more difficult to guarantee interoperability because subtle differences in an implementation could produce different results. At IETF97 significant feedback was received preferring a simpler solution t= o the problem. The authors are very sympathetic to this feedback and therefor= e are proposing a solution based on what the draft defines as the "Ignore" policy - where all entries which are in conflict are ignored. We believe th= is is far more desirable and aligns with the priorities listed above. We outline the proposed solution below and would like to receive feedback f= rom the WG before publishing the next revision of the draft. Les (on behalf of the authors) New Proposal In the latest revision of the draft "SRMS Preference" was introduced. This provides a way for a numerical preference to be explicitly associated with = an SRMS advertisement. Using this an operator can indicate which advertisement= is to be preferred when a conflict is present. The authors think this is a use= ful addition and we therefore want to include this in the new solution. The new preference rule used to resolve conflicts is defined as follows: A given mapping entry is compared against all mapping entries in the databa= se with a preference greater than or equal to its own. If there is a conflict, the mapping entry with lower preference is ignored. If two mapping entries = are in conflict and have equal preference then both entries are ignored. Implementation of this policy is defined as follows: Step 1: Within a single address-family/algorithm/topology sort entries based on preference Step 2: Starting with the lowest preference entries, resolve prefix conflic= ts using the above preference rule. The output is an active policy per topolog= y. Step 3: Take the outputs from Step 2 and again sort them by preference Step 4: Starting with the lowest preference entries, resolve SID conflicts using the above preference rule The output from Step 4 is then the current Active Policy. Here are a few examples. Each mapping entry is represented by the tuple: (Preference, Prefix/mask Index range <#>) Example 1: 1. (150, 1.1.1.1/32 100 range 100) 2. (149, 1.1.1.10/32 200 range 200) 3. (148, 1.1.1.101/32 500 range 10) Entry 3 conflicts with entry 2, it is ignored. Entry 2 conflicts with entry 1, it is ignored. Active policy: (150, 1.1.1.1/32 100 range 100) Example 2: 1. (150, 1.1.1.1/32 100 range 100) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entry 2, both are marked as ignore. Entry 3 conflicts with entry 2. It is marked as ignore. Entry 4 has no conflicts with any entries Active policy: (150, 2.2.2.1/32 1000 range 1) Example 3: 1. (150, 1.1.1.1/32 100 range 500) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entries 2, 3, and 4. All entries are marked ignore. Active policy: Empty Example 4: 1. (150, 1.1.1.1/32 100 range 10) 2. (149, 1.1.1.10/32 200 range 300) 3. (149, 1.1.1.101/32 500 range 10) 4. (148, 2.2.2.1/32 1000 range 1) Entry 4 conflicts with entry 2. It is marked ignore. Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore. Active policy: (150, 1.1.1.1/32 100 range 10) --_000_41bfb2542a984dc29ef0b99fecf06de2XCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mustapha –<= /o:p>

 

Some responses inline,= but I emphasize again that the most important issue being discussed at the= moment is what to do when conflicts are detected. There are two proposals:=

 

1)Do not use the SIDs = which are in conflict (“Ignore”)

2)Use some conflict re= solution algorithm to choose how to use the conflicting SIDs (“Ignore= overlap only”)

 

I would encourage you = and everyone else to comment on that.

 

If we choose #2 above = then the specific preference rule (currently defined in Section 3.3.4 of th= e draft) can be reviewed – but not much point in doing so until we de= cide whether we are going to use a preference rule at all.

 

From: Aissaoui= , Mustapha (Nokia - CA) [mailto:mustapha.aissaoui@nokia.com]
Sent: Friday, December 23, 2016 6:59 AM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

Hi Les,

I made some follow-up inline.<= /span>

 

Regards,

Mustapha.

 

From: Les Ginsberg (ginsberg) [mailto:ginsber= g@cisco.com]
Sent: Thursday, December 22, 2016 2:37 PM
To: Aissaoui, Mustapha (Nokia - CA) <mustapha.aissaoui@nokia.com&= gt;; spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /p>

 

Mustapha -<= /span>

 

 

Hi Les,

I read slides 17-21 of the document you r= eferenced below and I have the following comments:

 

1.     Page 17, “Order Matters - Prefix vs SID Conflict= 221;.

When you perform resolution on&nbs= p; a per prefix basis, prefix conflicts are naturally processed first follo= wed by SID conflicts across different prefixes. So the ordering issue described is only specific if you decided to resolve conflicting SID= entries outside of the natural prefix resolution by a router.

 

[Les:] What may seem “natural” to you might = not to someone else. I don’t care to debate that point. What is being= illustrated here is that in order to provide a normative specification that – if followed – guarantees interoperability= we have to specify the order in which conflicts are processed otherwise di= fferent results may be obtained.

 

MA> I agree on the intent of specifyin= g a procedure which achieves interoperability. However, it seems to me this= draft is ignoring the fact that routers do per-prefix resolution and is trying to perform the SID resolution outside of it.

[Les2:] Section = 3.2 of the draft details the types of conflicts which may occur. These incl= ude:

 

  1)Prefix = conflicts – different SIDs assigned to the same prefix

2)SID conflicts = – multiple prefixes associated with the same SID

 

The term “= pre-prefix resolution” suggests to me that you think all we have to d= o is find all the SID advertisements associated with a given prefix in orde= r to determine whether we have a conflict or not. But that only finds “prefix conflicts” – it does not fin= d SID conflicts – and both have to be dealt with.

If you mean some= thing else please clarify.

 

2.     Page 18, “Order Matters: Derived vs non-derivedR= 11; prefix conflict”.

It seems to me this issue is an ar= tifact of the specific algorithm used to resolve conflicts. Because the alg= orithm uses parameters such as “Range (start w smallest)” then obviously derived SRMS entries will lend a different result than orig= inal SRMS entries.

With the pre-prefix resolution, th= e only information kept from the original SRMS entry is the preference and = the advertising or owner router. Anything else is not used. It seems to me a simple algorithm based on preference first then followed = by some rule on selecting the advertising router if conflicts exist within = the same preference would work.

 

[Les:] You have implemented things in a certain way. Som= eone else might choose to implement in a different way. A normative specifi= cation does not (and should not) constrain an implementation. What is being illustrated here is that if the implement= ation does not retain the underived entry (in whatever internal form it cho= oses) different results will be obtained because the preference algorithm d= epends on comparing the underived ranges.

 

MA> I= do not believe this is about implementation. It is about what routers do a= nd that is resolution per prefix. It does not matter how the prefix SID information is advertised, individually or part of an SRMS entr= y, at the end it is associated with a prefix.

&nb= sp;

3.     Finally, there is something which has not been addressed = in the slides. There is still a possibility of conflicting entries among SI= Ds advertised using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV). A simple rule select= ing the advertising router should also work fine here.

 

[Les:] No –= ; source of an advertisement has been quite deliberately excluded from the = preference algorithm. With redistribution/route leaking the source of an ad= vertisement may appear to be different on different routers- this would result in different results on different rou= ters.

 

MA> The following RFC is specifying an= optional attribute (the IPv4/IPv6 Source Router ID TLV) to encode the orig= inal advertising router of a prefix. This can be used to perform a simple selection algorithm:

https://tools.ietf.org/html/rfc7794#section-2.2

 

Otherwise, what is your proposal for this= point (3)? I could not find it addressed in the current version of the dra= ft.

 

[Les2:] The prop= osal is NOT to use the source of an advertisement as an input to conflict r= esolution.

RFC 7794 only ad= dresses the issue for IS-IS and even then only for SIDs learned via prefix = reachability advertisements. Use of source still has consistency issues for= SRMS advertisements, OSPF, and cases which involve multiple protocol instances.

This choice has = been consciously made and is in part based on our experience with existing = implementations.

 

That said, this = issue is only relevant if you believe it is necessary/desirable to use a pr= eference rule to make a choice when a conflict exists.

The proponents o= f “Ignore” don’t want to do this – we want to NOT u= se SIDs which are in conflict. We believe this is less likely to lead to in= teroperability problems and is less likely to have undesirable side effects. It also prioritizes detection and reporting of conflicts.

 

   Les=

 

Regards,

Mustapha.

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, December 09, 2016 1:49 PM
To: Aissaoui, Mustapha (Nokia - CA) <mustapha.aissaoui@nokia.com>; spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /p>

 

Mustapha -<= /span>

 

From: Aissaoui= , Mustapha (Nokia - CA) [mai= lto:mustapha.aissaoui@nokia.com]
Sent: Friday, December 09, 2016 7:44 AM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

I have a couple of comments on the below = proposal.

 

1.     Regarding the SRMS Preference Sub-TLV in section 3.1 of t= he draft. In many cases, a configuration on the resolving router can assign= a preference to each SRMS in case there is no advertisement of this sub-TLV or to override an advertised value. I propose that this op= tion be allowed. Here is a proposed update to the relevant paragraph:<= /o:p>

“

           Ad= vertisement of a preference value is optional.  Nodes which do not

          adv= ertise a preference value are assigned a preference value of 128.  &nb= sp;            =         

          &nb= sp;A resolving router can override the default or= the advertised value by local policy.

“

[Les:] In order to get consistent conflict resolution on= all nodes in the network, it is necessary that they all have the same data= base – which includes the preference value. If you allow local policy to modify the preference you no longer have cons= istent databases on all nodes and we can no longer guarantee consistent con= flict resolution. So your proposal is not viable IMO.

 

2.     I am trying to understand the concept of sorting SRMS ent= ries which have different prefixes and different range sizes.  

Since a SID advertised in a prefix= SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefi= x TLV) has higher priority over a SID for the same prefix advertised from a SRMS, then you have to add to the below sorting an entry= for each individual prefix which advertised a prefix SID sub-TLV within a = prefix TLV.

At this point, the concept of an e= ntry with multiple prefixes is moot and you may as well just sort on a per = prefix basis which is the most natural thing to do given that the prefix resolution and then the SID resolution are performed on a = per prefix basis. SID conflicts can be resolved on a per prefix basis using= the below proposed preference algorithm without having to ignore SID value= s for unrelated prefixes just because it happens that they were advertised in the same SRMS entry.

 

[Les:] The simpler proposal does not require sorting on = anything other than preference. After that, you can process entries in any = order you want and you will get the same answer.

With “Ignore Overlap Only” one of the issues= with trying to use the non-conflicting portions of a mapping entry which h= as a range > 1 is that the order in which you process entries influences the result. Please see slides 17 – 20 from the IE= TF97 presentation: https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-= ietf-spring-conflict-resolution-02-00.pptx for some simple examples of = this.

 

   Les

 

 

Regards,

Mustapha.

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Sunday, December 04, 2016 7:04 PM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal

 

When the problem addressed by draft-ietf-spring-c= onflict-resolution was first

presented at IETF 94, the authors defined the fol= lowing priorities:

 

1)Detect the problem

2)Report the problem

This alerts the network operator to the existence= of a conflict so that

the configuration error can be corrected.

3)Define consistent behavior

This avoids mis-forwarding while the conflict exi= sts.

4)Don’t overengineer the solution

Given that it is impossible to know which of the = conflicting entries

is the correct one, we should apply a simple algo= rithm to resolve the conflict.

5)Agree on the resolution behavior

 

The resolution behavior was deliberately the last= point because it was

considered the least important.

 

Input was received over the past year which empha= sized the importance of

trying to "maximize forwarding" in the = presence of conflicts. Subsequent

revisions of the draft have tried to address this= concern. However the authors

have repeatedly stressed that the solution being = proposed

("ignore overlap only") was more comple= x than other offered alternatives and

would be more difficult to guarantee interoperabi= lity because subtle

differences in an implementation could produce di= fferent results.

 

At IETF97 significant feedback was received prefe= rring a simpler solution to

the problem. The authors are very sympathetic to = this feedback and therefore

are proposing a solution based on what the draft = defines as the "Ignore"

policy - where all entries which are in conflict = are ignored. We believe this

is far more desirable and aligns with the priorit= ies listed above.

 

We outline the proposed solution below and would = like to receive feedback from

the WG before publishing the next revision of the= draft.

 

   Les (on behalf of the authors)<= /o:p>

 

New Proposal

 

In the latest revision of the draft "SRMS= Preference" was introduced. This

provides a way for a numerical preference to b= e explicitly associated with an

SRMS advertisement. Using this an operator can= indicate which advertisement is

to be preferred when a conflict is present. Th= e authors think this is a useful

addition and we therefore want to include this= in the new solution.

 

The new preference rule used to resolve confli= cts is defined as follows:

 

A given mapping entry is compared against a= ll mapping entries in the database

with a preference greater than or equal to = its own. If there is a conflict,

the mapping entry with lower preference is = ignored. If two mapping entries are

in conflict and have equal preference then = both entries are ignored.

 

Implementation of this policy is defined as fo= llows:

 

Step 1: Within a single address-family/algo= rithm/topology sort entries

based on preference

Step 2: Starting with the lowest preference= entries, resolve prefix conflicts

using the above preference rule. The output= is an active policy per topology.

Step 3: Take the outputs from Step 2 and ag= ain sort them by preference

Step 4: Starting with the lowest preference= entries, resolve SID conflicts

using the above preference rule<= /i>

 

The output from Step 4 is then the current = Active Policy.

 

Here are a few examples. Each mapping entry is re= presented by the tuple:

(Preference, Prefix/mask Index range <#>)

 

Example 1:

 

1. (150, 1.1.1.1/32 100 range 100)

2. (149, 1.1.1.10/32 200 range 200)

3. (148, 1.1.1.101/32 500 range 10)

 

Entry 3 conflicts with entry 2, it is ignored.

Entry 2 conflicts with entry 1, it is ignored.

Active policy:

 

(150, 1.1.1.1/32 100 range 100)

 

Example 2:

 

1. (150, 1.1.1.1/32 100 range 100)

2. (150, 1.1.1.10/32 200 range 200)

3. (150, 1.1.1.101/32 500 range 10)

4. (150, 2.2.2.1/32 1000 range 1)

 

Entry 1 conflicts with entry 2, both are marked a= s ignore.

Entry 3 conflicts with entry 2. It is marked as i= gnore.

Entry 4 has no conflicts with any entries

 

Active policy:

(150, 2.2.2.1/32 1000 range 1)

 

Example 3:

 

1. (150, 1.1.1.1/32 100 range 500)

2. (150, 1.1.1.10/32 200 range 200)

3. (150, 1.1.1.101/32 500 range 10)

4. (150, 2.2.2.1/32 1000 range 1)

 

Entry 1 conflicts with entries 2, 3, and  4.= All entries are marked ignore.

 

Active policy:

Empty

 

Example 4:

 

1. (150, 1.1.1.1/32 100 range 10)

2. (149, 1.1.1.10/32 200 range 300)

3. (149, 1.1.1.101/32 500 range 10)

4. (148, 2.2.2.1/32 1000 range 1)

 

Entry 4 conflicts with entry 2. It is marked igno= re.

Entry 2 conflicts with entry 3. Entries 2 and 3 a= re marked ignore.

 

Active policy:

(150, 1.1.1.1/32 100 range 10)

 

 

 

 

--_000_41bfb2542a984dc29ef0b99fecf06de2XCHALN001ciscocom_-- From nobody Sun Jan 1 09:25:13 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 BDEE2126CD8 for ; Sun, 1 Jan 2017 09:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 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=-3.1, 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 TbdNe1tiCf5X for ; Sun, 1 Jan 2017 09:25:09 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F96126BF7 for ; Sun, 1 Jan 2017 09:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20841; q=dns/txt; s=iport; t=1483291509; x=1484501109; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DxQU7L8EYaKwbTUdG8psEaPWP7hMU7U2sIoAlvTnBuM=; b=XRsEadtyAfCsnEc0/MmDnXztIflHqoNJGsWTal4xiJ0NkdCAHyUZJ/t2 DWjgBTti4J9pu5eAUZSi7bwXJ9O1YUZecSybG/j3nmgAZ3C8oe2LKM66B XGPMU2jdDfAgUIDvvQhn7r8jiOoq3FO6fjHraBmuTzHo5Bxsk0jdOPoRk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQDCOmlY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9fgQwHjVCUQ4d7jSCCCB8NhSxKAoFfPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBAwEBASUTMQMLDAQCAQgRBAEBAR4JByEGCxQJCAIEAQ0FCBECi?= =?us-ascii?q?DoDEAgOsRk6hyINgwkBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZFhGGCToFiQoU?= =?us-ascii?q?1BZpINQGJZYNfg3CBfoUIg0qGDod+gXWEO4QOAR84SmAug2McgV5yhgMrgQOBD?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,432,1477958400"; d="scan'208";a="367517567" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jan 2017 17:25:07 +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 v01HP6sP020496 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 1 Jan 2017 17:25:07 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, 1 Jan 2017 11:25:06 -0600 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, 1 Jan 2017 11:25:06 -0600 From: "Les Ginsberg (ginsberg)" To: Marc Binderberger , "Aissaoui, Mustapha (Nokia - CA)" , Robert Raszuk Thread-Topic: [spring] SID Conflict Resolution: A Simpler Proposal Thread-Index: AdJOibcaOvA8JiDrT2eiOTpEk40qzwDAodWgAC/MMoAChMj6cAAKwMEwAA1jLAAACT8g0P//4f2AgAEbxoCADBSGgP/+NNoA Date: Sun, 1 Jan 2017 17:25:06 +0000 Message-ID: References: <84fe7b43d5054712abf09b274bc3c471@XCH-ALN-001.cisco.com> <4A79394211F1AF4EB57D998426C9340DD4AFFBBF@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340DD4B100A7@US70UWXCHMBA01.zam.alcatel-lucent.com> <63a79609cc964132a1f67cb75da98cf7@XCH-ALN-001.cisco.com> <4A79394211F1AF4EB57D998426C9340DD4B11684@US70UWXCHMBA01.zam.alcatel-lucent.com> <20161230235329792752.772c609e@sniff.de> In-Reply-To: <20161230235329792752.772c609e@sniff.de> 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.117.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jan 2017 17:25:12 -0000 Marc > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, December 30, 2016 11:53 PM > To: Aissaoui, Mustapha (Nokia - CA); Robert Raszuk; Les Ginsberg (ginsber= g) > Cc: spring@ietf.org > Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal >=20 >=20 > mind-boggling discussion :-) >=20 > Hello SR experts. >=20 >=20 > Mustapha wrote >=20 > > I have the impression the authors are trying to address SID conflict > > resolution outside of the natural per prefix resolution on the router. >=20 > that was my thought too. From the routing protocol I deal with a prefix. = Then > I need to find the SID for the prefix to program my ingress/egress labels= . If > the mapping prefix -> SID has conflicting results _then_ I have a problem= . >=20 >=20 > Or in other words: >=20 > 1. (150, 1.1.1.1/32 100 range 100) > 2. (150, 1.1.1.1/32 500 range 2) >=20 > would result in no mapping, following the new proposal. All due to a typo= of > 1.1.1.1 instead of 1.1.2.1 in the 2nd mapping? While I understand the > algorithm I don't want to be the poor operator having my OSS screen full = with > alarms for 1.1.1.3..100 . >=20 >=20 > Btw, the "preference" field, what purpose does is serve? Has this been > introduced solely to tie-break conflicts? So we have one more parameter > that can be typo-d :-) Or is there actually an application for it? [Les:] Preference has been introduced primarily to support introduction of = a new mapping servers in a safer manner. It also can support non-disruptive= migration from an LDP enabled network to an SR enabled network. Consider the simple example of wanting to bring up a new mapping server in = a live network. One can introduce the new SRMS advertisements with a prefer= ence of "0" - so they won't be used but will be advertised. Advertisements = can then be validated by all nodes (e.g. implementations could provide info= rmational report of conflicts even when the conflicting advertisements are = not actually being used to determine what to install in the forwarding plan= e) before they are put into use. HTH Les >=20 >=20 > Robert wrote >=20 > > After mental reset I conclude that perhaps even the introduction of > > the draft is questionable >=20 > That goes much further than what I had in mind ;-) but I wonder if we go = too > far. I still think it is useful to describe what is a conflict - and this= way also > saying what should not be mistaken for a conflict. The discussion about > conflict-with-range vs. conflict-with-prefix seems useful to me. >=20 > My problem with the earlier drafts was more about the conflict > resolution/reaction, I found it complex and too specific to generally agr= ee on. > My personal opinion is when you have a conflict then _drop_ the prefix > traffic. But quite frankly "dropping", "not programming", "strip to IP" o= r > whatever else, they are all simple operations. Or simple code path, as > Stewart put it, as long as we stick to _one_ of them. The draft should > demand one particular operation to be a MUST for interoperability. >=20 >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Fri, 23 Dec 2016 15:24:55 +0000, Aissaoui, Mustapha (Nokia - CA) wrote= : > > Hi Robert, > > In fact you are touching on the point I am trying to make in my > > comment (1) on the slides. Reading this draft, I have the impression > > the authors are trying to address SID conflict resolution outside of > > the natural per prefix resolution on the router. While in theory this > > can be done but it makes the algorithm much more complex trying to > > compare overlapping SRMS SID entries with different range sizes. > > > > There are two sources of advertisement of the SID information: > > a. Per-prefix SID entries received in the prefix SID sub-TLV withi= n a > > Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV). > > b. SRMS entries which advertise SID information for a range of pref= ixes. > > > > The range size of the SRMS entry entirely depends on how the user > > wants to advertise the information and has no meaning for the > > resolution. From a router's perspective, the SID information is > > associated with a prefix regardless how it is advertised. > > > > The per-prefix SID information is preferred to the SRMS SID information= . > > And thus a simple algorithm which at the top level selects the SID > > among set (a) based on the source advertising router and if empty > > selects the SID among set (b) based on the SRMS preference and then > > based on the SRMS router-id if same preference will work. > > > > Regards, > > Mustapha. > > > > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > > Raszuk > > Sent: Thursday, December 22, 2016 5:29 PM > > To: Les Ginsberg (ginsberg) > > Cc: Aissaoui, Mustapha (Nokia - CA) ; > > spring@ietf.org > > Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal > > > > Les, > > > > After mental reset I conclude that perhaps even the introduction of > > the draft is questionable as in real life it applies to be quite an > > unrealistic scenario to have a situation where more then one protocol > > is used *in the same time* as active in forwarding for an exact same IP > prefix. > > > > Last time I checked SIDs are meaningless without a prefix they are > > attached to and it is a prefix they accompany to indicate which SID > > should be used on a given node. > > > > Therefor if you consider that today most implementations pretty well > > can handle overlapping prefixes from multiple sources what real > > problem is this draft solving ? > > > > Are you trying to create a forwarding graph by SIDs only detaching > > them from IP prefixes all together ? > > > > Cheers, > > R. > > > > > > On Thu, Dec 22, 2016 at 10:32 PM, Les Ginsberg (ginsberg) > > wrote: > >> Robert - > >> > >> You have a complete misunderstanding of roles here. > >> > >> How the owner of a route may be represented in the RIB isn't impacted > >> by SRMS or conflict resolution. Nor is the determination of which > >> route is the best route. We are only determining whether to use or > >> not use a SID which was associated with the prefix by some > advertisement. > >> > >> The Introduction to the draft states: > >> > >> "The problem to be addressed is protocol independent i.e., segment > >> related advertisements may be originated by multiple nodes using > >> different protocols and yet the conflict resolution MUST be the sam= e > >> on all nodes regardless of the protocol used to transport the > >> advertisements." > >> > >> Please do a mental reset. J > >> > >> Les > >> > >> > >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of > >> Robert Raszuk > >> Sent: Thursday, December 22, 2016 11:52 AM > >> To: Les Ginsberg (ginsberg) > >> Cc: Aissaoui, Mustapha (Nokia - CA); spring@ietf.org > >> > >> Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal > >> > >> Hi Les, > >> > >> On #1 I am also with Mustapha here. For clarity of this discussion > >> can you enumerate when from RIB to FIB/LFIB you are installing the > >> exact same active prefix from more then one producer ? Is SRMS sort > >> of zombie here and not treated as real route producer hence we have > >> an issue ? And the issue is only with conflicts of SRMS + real route > producer ? > >> > >> On #3 you said that "with redistribution/route leaking the source of > >> an advertisement may appear to be different on different routers" > >> that is very true. In fact with simple static route or static label > >> configured on a router the RIB and FIB on that router will be > >> different then RIB and FIB on the other routers without such static > >> route. And the point is that such static route or label is there for > >> a reason you may not know about. So struggling for data plane > >> consistency deliberately excluding source when operational needs > >> require otherwise is not really that much helpful I am afraid. > >> > >> Greetings, > >> Robert. > >> > >> > >> On Thu, Dec 22, 2016 at 8:37 PM, Les Ginsberg (ginsberg) > >> wrote: > >> Mustapha - > >> > >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, > >> Mustapha (Nokia - CA) > >> Sent: Thursday, December 22, 2016 8:10 AM > >> To: Les Ginsberg (ginsberg); spring@ietf.org > >> Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal > >> > >> Hi Les, > >> I read slides 17-21 of the document you referenced below and I have > >> the following comments: > >> > >> 1. Page 17, "Order Matters - Prefix vs SID Conflict". > >> When you perform resolution on a per prefix basis, prefix conflicts > >> are naturally processed first followed by SID conflicts across > >> different prefixes. So the ordering issue described is only specific > >> if you decided to resolve conflicting SID entries outside of the > >> natural prefix resolution by a router. > >> > >> [Les:] What may seem "natural" to you might not to someone else. I don= ' > >> t care to debate that point. What is being illustrated here is that > >> in order to provide a normative specification that - if followed - > >> guarantees interoperability we have to specify the order in which > >> conflicts are processed otherwise different results may be obtained. > >> > >> 2. Page 18, "Order Matters: Derived vs non-derived- prefix conflic= t" > >> . > >> It seems to me this issue is an artifact of the specific algorithm > >> used to resolve conflicts. Because the algorithm uses parameters such > >> as "Range (start w smallest)" then obviously derived SRMS entries > >> will lend a different result than original SRMS entries. > >> With the pre-prefix resolution, the only information kept from the > >> original SRMS entry is the preference and the advertising or owner rou= ter. > >> Anything else is not used. It seems to me a simple algorithm based on > >> preference first then followed by some rule on selecting the > >> advertising router if conflicts exist within the same preference would > work. > >> > >> [Les:] You have implemented things in a certain way. Someone else > >> might choose to implement in a different way. A normative > >> specification does not (and should not) constrain an implementation. > >> What is being illustrated here is that if the implementation does not > >> retain the underived entry (in whatever internal form it chooses) > >> different results will be obtained because the preference algorithm > depends on comparing the underived ranges. > >> > >> 3. Finally, there is something which has not been addressed in the > >> slides. There is still a possibility of conflicting entries among > >> SIDs advertised using the prefix SID sub-TLV within a Prefix TLV > >> (IS-IS IP Reach TLV or OSPF Extended Prefix TLV). A simple rule > >> selecting the advertising router should also work fine here. > >> > >> [Les:] No - source of an advertisement has been quite > >> > >> deliberately excluded from the preference algorithm. With > >> redistribution/route leaking the source of an advertisement may > >> appear to be different on different routers- this would result in > >> different results on different routers. > >> > >> Les > >> > >> Regards, > >> Mustapha. > >> > >> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > >> Sent: Friday, December 09, 2016 1:49 PM > >> To: Aissaoui, Mustapha (Nokia - CA) ; > >> spring@ietf.org > >> Subject: RE: SID Conflict Resolution: A Simpler Proposal > >> > >> Mustapha - > >> > >> From: Aissaoui, Mustapha (Nokia - CA) > >> [mailto:mustapha.aissaoui@nokia.com] > >> Sent: Friday, December 09, 2016 7:44 AM > >> To: Les Ginsberg (ginsberg); spring@ietf.org > >> Subject: RE: SID Conflict Resolution: A Simpler Proposal > >> > >> I have a couple of comments on the below proposal. > >> > >> 1. Regarding the SRMS Preference Sub-TLV in section 3.1 of the dra= ft. > >> In many cases, a configuration on the resolving router can assign a > >> preference to each SRMS in case there is no advertisement of this > >> sub-TLV or to override an advertised value. I propose that this option= be > allowed. > >> Here is a proposed update to the relevant paragraph: > >> " > >> Advertisement of a preference value is optional. Nodes > >> which do not > >> advertise a preference value are assigned a preference value= of > >> 128. > >> A resolving router can override the default or the > >> advertised value by local policy. > >> " > >> [Les:] In order to get consistent conflict resolution on all nodes in > >> the network, it is necessary that they all have the same database - > >> which includes the preference value. If you allow local policy to > >> modify the preference you no longer have consistent databases on all > >> nodes and we can no longer guarantee consistent conflict resolution. > >> So your proposal is not viable IMO. > >> > >> 2. I am trying to understand the concept of sorting SRMS entries w= hich > >> have different prefixes and different range sizes. > >> Since a SID advertised in a prefix SID sub-TLV within a Prefix TLV > >> (IS-IS IP Reach TLV or OSPF Extended Prefix TLV) has higher priority > >> over a SID for the same prefix advertised from a SRMS, then you have > >> to add to the below sorting an entry for each individual prefix which > >> advertised a prefix SID sub-TLV within a prefix TLV. > >> At this point, the concept of an entry with multiple prefixes is moot > >> and you may as well just sort on a per prefix basis which is the most > >> natural thing to do given that the prefix resolution and then the SID > >> resolution are performed on a per prefix basis. SID conflicts can be > >> resolved on a per prefix basis using the below proposed preference > >> algorithm without having to ignore SID values for unrelated prefixes > >> just because it happens that they were advertised in the same SRMS > entry. > >> > >> [Les:] The simpler proposal does not require sorting on anything > >> other than preference. After that, you can process entries in any > >> order you want and you will get the same answer. > >> With "Ignore Overlap Only" one of the issues with trying to use the > >> non-conflicting portions of a mapping entry which has a range > 1 is > >> that the order in which you process entries influences the result. > >> Please see slides 17 - 20 from the IETF97 presentation: > >> > https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draf= t- > ietf-spring-conflict-resolution-02-00.pptx > >> for some simple examples of this. > >> > >> Les > >> > >> > >> Regards, > >> Mustapha. > >> > >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les > >> Ginsberg > >> (ginsberg) > >> Sent: Sunday, December 04, 2016 7:04 PM > >> To: spring@ietf.org > >> Subject: [spring] SID Conflict Resolution: A Simpler Proposal > >> > >> When the problem addressed by draft-ietf-spring-conflict-resolution > >> was first presented at IETF 94, the authors defined the following > >> priorities: > >> > >> 1)Detect the problem > >> 2)Report the problem > >> This alerts the network operator to the existence of a conflict so > >> that the configuration error can be corrected. > >> 3)Define consistent behavior > >> This avoids mis-forwarding while the conflict exists. > >> 4)Don't overengineer the solution > >> Given that it is impossible to know which of the conflicting entries > >> is the correct one, we should apply a simple algorithm to resolve the > >> conflict. > >> 5)Agree on the resolution behavior > >> > >> The resolution behavior was deliberately the last point because it > >> was considered the least important. > >> > >> Input was received over the past year which emphasized the importance > >> of trying to "maximize forwarding" in the presence of conflicts. > >> Subsequent revisions of the draft have tried to address this concern. > >> However the authors have repeatedly stressed that the solution being > >> proposed ("ignore overlap only") was more complex than other offered > >> alternatives and would be more difficult to guarantee > >> interoperability because subtle differences in an implementation > >> could produce different results. > >> > >> At IETF97 significant feedback was received preferring a simpler > >> solution to the problem. The authors are very sympathetic to this > >> feedback and therefore are proposing a solution based on what the > >> draft defines as the "Ignore" > >> policy - where all entries which are in conflict are ignored. We > >> believe this is far more desirable and aligns with the priorities > >> listed above. > >> > >> We outline the proposed solution below and would like to receive > >> feedback from the WG before publishing the next revision of the > >> draft. > >> > >> Les (on behalf of the authors) > >> > >> New Proposal > >> > >> In the latest revision of the draft "SRMS Preference" was introduced. > >> This provides a way for a numerical preference to be explicitly > >> associated with an SRMS advertisement. Using this an operator can > >> indicate which advertisement is to be preferred when a conflict is > >> present. The authors think this is a useful addition and we therefore > >> want to include this in the new solution. > >> > >> The new preference rule used to resolve conflicts is defined as follow= s: > >> > >> A given mapping entry is compared against all mapping entries in the > >> database with a preference greater than or equal to its own. If there > >> is a conflict, the mapping entry with lower preference is ignored. If > >> two mapping entries are in conflict and have equal preference then > >> both entries are ignored. > >> > >> Implementation of this policy is defined as follows: > >> > >> Step 1: Within a single address-family/algorithm/topology sort > >> entries based on preference Step 2: Starting with the lowest > >> preference entries, resolve prefix conflicts using the above > >> preference rule. The output is an active policy per topology. > >> Step 3: Take the outputs from Step 2 and again sort them by > >> preference Step 4: Starting with the lowest preference entries, > >> resolve SID conflicts using the above preference rule > >> > >> The output from Step 4 is then the current Active Policy. > >> > >> Here are a few examples. Each mapping entry is represented by the > tuple: > >> (Preference, Prefix/mask Index range <#>) > >> > >> Example 1: > >> > >> 1. (150, 1.1.1.1/32 100 range 100) > >> 2. (149, 1.1.1.10/32 200 range 200) > >> 3. (148, 1.1.1.101/32 500 range 10) > >> > >> Entry 3 conflicts with entry 2, it is ignored. > >> Entry 2 conflicts with entry 1, it is ignored. > >> Active policy: > >> > >> (150, 1.1.1.1/32 100 range 100) > >> > >> Example 2: > >> > >> 1. (150, 1.1.1.1/32 100 range 100) > >> 2. (150, 1.1.1.10/32 200 range 200) > >> 3. (150, 1.1.1.101/32 500 range 10) > >> 4. (150, 2.2.2.1/32 1000 range 1) > >> > >> Entry 1 conflicts with entry 2, both are marked as ignore. > >> Entry 3 conflicts with entry 2. It is marked as ignore. > >> Entry 4 has no conflicts with any entries > >> > >> Active policy: > >> (150, 2.2.2.1/32 1000 range 1) > >> > >> Example 3: > >> > >> 1. (150, 1.1.1.1/32 100 range 500) > >> 2. (150, 1.1.1.10/32 200 range 200) > >> 3. (150, 1.1.1.101/32 500 range 10) > >> 4. (150, 2.2.2.1/32 1000 range 1) > >> > >> Entry 1 conflicts with entries 2, 3, and 4. All entries are marked ig= nore. > >> > >> Active policy: > >> Empty > >> > >> Example 4: > >> > >> 1. (150, 1.1.1.1/32 100 range 10) > >> 2. (149, 1.1.1.10/32 200 range 300) > >> 3. (149, 1.1.1.101/32 500 range 10) > >> 4. (148, 2.2.2.1/32 1000 range 1) > >> > >> Entry 4 conflicts with entry 2. It is marked ignore. > >> Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore. > >> > >> Active policy: > >> (150, 1.1.1.1/32 100 range 10) > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 Sun Jan 1 14:43: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 0D8C11270B4 for ; Sun, 1 Jan 2017 14:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 v2W9_h4k-2Be for ; Sun, 1 Jan 2017 14:43:13 -0800 (PST) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id 63FF8129408 for ; Sun, 1 Jan 2017 14:43:13 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 00E914BCFE8; Sun, 1 Jan 2017 22:43:10 +0000 (UTC) Date: Sun, 1 Jan 2017 14:43:10 -0800 From: Marc Binderberger To: Les Ginsberg (ginsberg) Message-ID: <20170101144310404287.c13409bc@sniff.de> In-Reply-To: <41bfb2542a984dc29ef0b99fecf06de2@XCH-ALN-001.cisco.com> References: <84fe7b43d5054712abf09b274bc3c471@XCH-ALN-001.cisco.com> <4A79394211F1AF4EB57D998426C9340DD4AFFBBF@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340DD4B100A7@US70UWXCHMBA01.zam.alcatel-lucent.com> <63a79609cc964132a1f67cb75da98cf7@XCH-ALN-001.cisco.com> <4A79394211F1AF4EB57D998426C9340DD4B115EF@US70UWXCHMBA01.zam.alcatel-lucent.com> <41bfb2542a984dc29ef0b99fecf06de2@XCH-ALN-001.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: base64 X-Mailer: GyazMail version 1.5.17 Archived-At: Cc: "spring@ietf.org" , "Aissaoui, Mustapha \(Nokia - CA\)" Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jan 2017 22:43:17 -0000 SGVsbG8gTGVzLA0KDQpJIGNhbm5vdCBoZWxwIGJ1dCB0aGlua2luZyB3ZSBnZXQgY2Fycmll ZCBhd2F5IHdpdGggdGhlIFNSTVMgcmFuZ2VzLiBGb3IgbWUgDQp0aGUgYWN0dWFsIG1lYW5p bmcgb2YgYSByYW5nZSBsYXlzIGluIGl0J3MgZXhwYW5kZWQgZm9ybTsgd2l0aCB0aGlzIEkg bWVhbg0KDQooPHByZWY+LCAxMC4xLjEuMS8zMiwgMTAwLCByYW5nZSAzKSBpcyBleHBhbmRl ZA0KDQogICAgMTAuMS4xLjEvMzIgLT4gU0lEIDEwMA0KICAgIDEwLjEuMS4yLzMyIC0+IFNJ RCAxMDENCiAgICAxMC4xLjEuMy8zMiAtPiBTSUQgMTAyDQoNCg0KSWYgeW91IHRha2UgaXQg ZnJvbSB0aGUgZXhwYW5kZWQgZm9ybSB0aGVuIHdlIGhhdmUgdGhlICJJZ25vcmUgb3Zlcmxh cCBvbmx5Ii4gDQpUaGF0IGlzIGhvdyBJIHVuZGVyc3RhbmQgdGhlIHBocmFzZSAicGVyLXBy ZWZpeCIuIEkgd291bGQgcHJlZmVyIHRvIGRpc2N1c3MgDQp0aGUgcHJlZml4IG9yIFNJRCBj b25mbGljdCBvbiB0aGlzIGV4cGFuZGVkLCBwZXItcHJlZml4IGJhc2lzLiBFLmcuIGZvciB0 aGUgDQpleGFtcGxlDQoNCjEuICgxNTAsIDEuMS4xLjEvMzIgMTAwIHJhbmdlIDEwMCkNCjIu ICgxNTAsIDEuMS4xLjEvMzIgNTAwIHJhbmdlIDIpDQoNCndpdGggdGhlIHR5cG8vbWlzdGFr ZSBvZiAxLjEuMS4xIGluc3RlYWQgb2YgMS4xLjIuMSBpbiB0aGUgMm5kIHJhbmdlIEkgZG9u J3QgDQpzZWUgd2h5IHByZWZpeGVzIDEuMS4xLjMvMzIgLSAxLjEuMS4xMDAvMzIgc2hvdWxk IG5vdCBiZSBtYXBwZWQgdG8gU0lEcyAxMDIgLSANCjE5OS4gVGhlIGNvbmZsaWN0IGlzIGZv ciAxLjEuMS4xLzMyIGFuZCAxLjEuMS4yLzMyIGFsb25lIGFuZCB0aGUgcXVlc3Rpb24gb2Yg DQpjb25mbGljdCByZXNvbHV0aW9uIGlzIGZvciB0aGVzZSB0d28gcHJlZml4ZXMgYWxvbmUu DQoNCg0KU2F5aW5nIHRoaXMsIGhhdmluZyBhIHdhcm5pbmcgdGhhdCB0aGVzZSB0d28gcmFu Z2VzIGNyZWF0ZSBhIGNvbmZsaWN0IHdvdWxkIA0KYmUgYSB1c2VmdWwgZGVidWdnaW5nIGlu Zm9ybWF0aW9uLg0KDQoNCkZvciB0aGUgYWN0aW9uLCBvbmNlIGEgY29uZmxpY3QgYmFzZWQg b24gdGhlIGV4cGFuZGVkIGZvcm0gaXMgZGV0ZWN0ZWQ6IEkgDQp3b3VsZCBwcmVmZXIgdG8g ZHJvcCB0aGUgdHJhZmZpYywgaS5lLiBpbiB0aGUgZXhhbXBsZSBhYm92ZQ0KDQogICAgMS4x LjEuMS8zMiAtPiBkcm9wDQogICAgMS4xLjEuMi8zMiAtPiBkcm9wDQoNCm5vciBzaG91bGQg dGhlcmUgYmUgYW55IGluZ3Jlc3MgbGFiZWwgcHJvZ3JhbW1lZCBmb3IgU0lEcyAxMDAsIDEw MSwgNTAwLCA1MDEuDQpCdXQgYXMgSSBzYWlkIGluIGFub3RoZXIgZW1haWwsIGFzIGxvbmcg YXMgd2UgY2FuIGFncmVlIG9uIGEgc2ltcGxlIGFjdGlvbiAtIA0KZHJvcCwgc3RyaXAgYWxs IGxhYmVscywgZG8gbm90IHByb2dyYW0gdGhlIHByZWZpeCAtIGFuZCBtYWtlIGl0IG1hbmRh dG9yeSANCnRoYXQgYWxsIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0IHRoaXMgb25lIGFjdGlv biB0aGVuIGZpbmUgd2l0aCBtZS4NCg0KDQoNClJlZ2FyZHMsIE1hcmMNCg0KDQoNCg0KT24g U3VuLCAxIEphbiAyMDE3IDE3OjE1OjE4ICswMDAwLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJn KSB3cm90ZToNCj4gTXVzdGFwaGEgoVYNCj4gIA0KPiBTb21lIHJlc3BvbnNlcyBpbmxpbmUs IGJ1dCBJIGVtcGhhc2l6ZSBhZ2FpbiB0aGF0IHRoZSBtb3N0IGltcG9ydGFudCBpc3N1ZSAN Cj4gYmVpbmcgZGlzY3Vzc2VkIGF0IHRoZSBtb21lbnQgaXMgd2hhdCB0byBkbyB3aGVuIGNv bmZsaWN0cyBhcmUgZGV0ZWN0ZWQuIA0KPiBUaGVyZSBhcmUgdHdvIHByb3Bvc2FsczoNCj4g IA0KPiAxKURvIG5vdCB1c2UgdGhlIFNJRHMgd2hpY2ggYXJlIGluIGNvbmZsaWN0ICihp0ln bm9yZaGoKQ0KPiAyKVVzZSBzb21lIGNvbmZsaWN0IHJlc29sdXRpb24gYWxnb3JpdGhtIHRv IGNob29zZSBob3cgdG8gdXNlIHRoZSANCj4gY29uZmxpY3RpbmcgU0lEcyAooadJZ25vcmUg b3ZlcmxhcCBvbmx5oagpDQo+ICANCj4gSSB3b3VsZCBlbmNvdXJhZ2UgeW91IGFuZCBldmVy eW9uZSBlbHNlIHRvIGNvbW1lbnQgb24gdGhhdC4NCj4gIA0KPiBJZiB3ZSBjaG9vc2UgIzIg YWJvdmUgdGhlbiB0aGUgc3BlY2lmaWMgcHJlZmVyZW5jZSBydWxlIChjdXJyZW50bHkgZGVm aW5lZCANCj4gaW4gU2VjdGlvbiAzLjMuNCBvZiB0aGUgZHJhZnQpIGNhbiBiZSByZXZpZXdl ZCChViBidXQgbm90IG11Y2ggcG9pbnQgaW4gDQo+IGRvaW5nIHNvIHVudGlsIHdlIGRlY2lk ZSB3aGV0aGVyIHdlIGFyZSBnb2luZyB0byB1c2UgYSBwcmVmZXJlbmNlIHJ1bGUgYXQgDQo+ IGFsbC4NCj4gIA0KPiBGcm9tOiBBaXNzYW91aSwgTXVzdGFwaGEgKE5va2lhIC0gQ0EpIFtt YWlsdG86bXVzdGFwaGEuYWlzc2FvdWlAbm9raWEuY29tXSANCj4gU2VudDogRnJpZGF5LCBE ZWNlbWJlciAyMywgMjAxNiA2OjU5IEFNDQo+IFRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJn KTsgc3ByaW5nQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBTSUQgQ29uZmxpY3QgUmVzb2x1 dGlvbjogQSBTaW1wbGVyIFByb3Bvc2FsDQo+ICANCj4gSGkgTGVzLA0KPiBJIG1hZGUgc29t ZSBmb2xsb3ctdXAgaW5saW5lLg0KPiAgDQo+IFJlZ2FyZHMsDQo+IE11c3RhcGhhLg0KPiAg DQo+IEZyb206IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIFttYWlsdG86Z2luc2JlcmdAY2lz Y28uY29tXSANCj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIyLCAyMDE2IDI6MzcgUE0N Cj4gVG86IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTm9raWEgLSBDQSkgPG11c3RhcGhhLmFpc3Nh b3VpQG5va2lhLmNvbT47IA0KPiBzcHJpbmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFNJ RCBDb25mbGljdCBSZXNvbHV0aW9uOiBBIFNpbXBsZXIgUHJvcG9zYWwNCj4gIA0KPiBNdXN0 YXBoYSAtDQo+ICANCj4gRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBBaXNzYW91aSwgDQo+IE11c3RhcGhhIChOb2tpYSAtIENB KQ0KPiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjIsIDIwMTYgODoxMCBBTQ0KPiBUbzog TGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IHNwcmluZ0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW3NwcmluZ10gU0lEIENvbmZsaWN0IFJlc29sdXRpb246IEEgU2ltcGxlciBQcm9wb3Nh bA0KPiAgDQo+IEhpIExlcywNCj4gSSByZWFkIHNsaWRlcyAxNy0yMSBvZiB0aGUgZG9jdW1l bnQgeW91IHJlZmVyZW5jZWQgYmVsb3cgYW5kIEkgaGF2ZSB0aGUgDQo+IGZvbGxvd2luZyBj b21tZW50czoNCj4gIA0KPiAxLiAgICAgUGFnZSAxNywgoadPcmRlciBNYXR0ZXJzIC0gUHJl Zml4IHZzIFNJRCBDb25mbGljdKGoLg0KPiBXaGVuIHlvdSBwZXJmb3JtIHJlc29sdXRpb24g b24gIGEgcGVyIHByZWZpeCBiYXNpcywgcHJlZml4IGNvbmZsaWN0cyBhcmUgDQo+IG5hdHVy YWxseSBwcm9jZXNzZWQgZmlyc3QgZm9sbG93ZWQgYnkgU0lEIGNvbmZsaWN0cyBhY3Jvc3Mg ZGlmZmVyZW50IA0KPiBwcmVmaXhlcy4gU28gdGhlIG9yZGVyaW5nIGlzc3VlIGRlc2NyaWJl ZCBpcyBvbmx5IHNwZWNpZmljIGlmIHlvdSBkZWNpZGVkIA0KPiB0byByZXNvbHZlIGNvbmZs aWN0aW5nIFNJRCBlbnRyaWVzIG91dHNpZGUgb2YgdGhlIG5hdHVyYWwgcHJlZml4IHJlc29s dXRpb24gDQo+IGJ5IGEgcm91dGVyLiANCj4gIA0KPiBbTGVzOl0gV2hhdCBtYXkgc2VlbSCh p25hdHVyYWyhqCB0byB5b3UgbWlnaHQgbm90IHRvIHNvbWVvbmUgZWxzZS4gSSBkb26hpnQg DQo+IGNhcmUgdG8gZGViYXRlIHRoYXQgcG9pbnQuIFdoYXQgaXMgYmVpbmcgaWxsdXN0cmF0 ZWQgaGVyZSBpcyB0aGF0IGluIG9yZGVyIA0KPiB0byBwcm92aWRlIGEgbm9ybWF0aXZlIHNw ZWNpZmljYXRpb24gdGhhdCChViBpZiBmb2xsb3dlZCChViBndWFyYW50ZWVzIA0KPiBpbnRl cm9wZXJhYmlsaXR5IHdlIGhhdmUgdG8gc3BlY2lmeSB0aGUgb3JkZXIgaW4gd2hpY2ggY29u ZmxpY3RzIGFyZSANCj4gcHJvY2Vzc2VkIG90aGVyd2lzZSBkaWZmZXJlbnQgcmVzdWx0cyBt YXkgYmUgb2J0YWluZWQuDQo+ICANCj4gTUE+IEkgYWdyZWUgb24gdGhlIGludGVudCBvZiBz cGVjaWZ5aW5nIGEgcHJvY2VkdXJlIHdoaWNoIGFjaGlldmVzIA0KPiBpbnRlcm9wZXJhYmls aXR5LiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZSB0aGlzIGRyYWZ0IGlzIGlnbm9yaW5nIHRo ZSBmYWN0IA0KPiB0aGF0IHJvdXRlcnMgZG8gcGVyLXByZWZpeCByZXNvbHV0aW9uIGFuZCBp cyB0cnlpbmcgdG8gcGVyZm9ybSB0aGUgU0lEIA0KPiByZXNvbHV0aW9uIG91dHNpZGUgb2Yg aXQuDQo+IFtMZXMyOl0gU2VjdGlvbiAzLjIgb2YgdGhlIGRyYWZ0IGRldGFpbHMgdGhlIHR5 cGVzIG9mIGNvbmZsaWN0cyB3aGljaCBtYXkgDQo+IG9jY3VyLiBUaGVzZSBpbmNsdWRlOg0K PiAgDQo+ICAgMSlQcmVmaXggY29uZmxpY3RzIKFWIGRpZmZlcmVudCBTSURzIGFzc2lnbmVk IHRvIHRoZSBzYW1lIHByZWZpeA0KPiAyKVNJRCBjb25mbGljdHMgoVYgbXVsdGlwbGUgcHJl Zml4ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIFNJRA0KPiAgDQo+IFRoZSB0ZXJtIKGn cHJlLXByZWZpeCByZXNvbHV0aW9uoaggc3VnZ2VzdHMgdG8gbWUgdGhhdCB5b3UgdGhpbmsg YWxsIHdlIA0KPiBoYXZlIHRvIGRvIGlzIGZpbmQgYWxsIHRoZSBTSUQgYWR2ZXJ0aXNlbWVu dHMgYXNzb2NpYXRlZCB3aXRoIGEgZ2l2ZW4gDQo+IHByZWZpeCBpbiBvcmRlciB0byBkZXRl cm1pbmUgd2hldGhlciB3ZSBoYXZlIGEgY29uZmxpY3Qgb3Igbm90LiBCdXQgdGhhdCANCj4g b25seSBmaW5kcyChp3ByZWZpeCBjb25mbGljdHOhqCChViBpdCBkb2VzIG5vdCBmaW5kIFNJ RCBjb25mbGljdHMgoVYgYW5kIA0KPiBib3RoIGhhdmUgdG8gYmUgZGVhbHQgd2l0aC4NCj4g SWYgeW91IG1lYW4gc29tZXRoaW5nIGVsc2UgcGxlYXNlIGNsYXJpZnkuDQo+ICANCj4gMi4g ICAgIFBhZ2UgMTgsIKGnT3JkZXIgTWF0dGVyczogRGVyaXZlZCB2cyBub24tZGVyaXZlZKFW IHByZWZpeCBjb25mbGljdKGoLg0KPiBJdCBzZWVtcyB0byBtZSB0aGlzIGlzc3VlIGlzIGFu IGFydGlmYWN0IG9mIHRoZSBzcGVjaWZpYyBhbGdvcml0aG0gdXNlZCB0byANCj4gcmVzb2x2 ZSBjb25mbGljdHMuIEJlY2F1c2UgdGhlIGFsZ29yaXRobSB1c2VzIHBhcmFtZXRlcnMgc3Vj aCBhcyChp1JhbmdlIA0KPiAoc3RhcnQgdyBzbWFsbGVzdCmhqCB0aGVuIG9idmlvdXNseSBk ZXJpdmVkIFNSTVMgZW50cmllcyB3aWxsIGxlbmQgYSANCj4gZGlmZmVyZW50IHJlc3VsdCB0 aGFuIG9yaWdpbmFsIFNSTVMgZW50cmllcy4gDQo+IFdpdGggdGhlIHByZS1wcmVmaXggcmVz b2x1dGlvbiwgdGhlIG9ubHkgaW5mb3JtYXRpb24ga2VwdCBmcm9tIHRoZSBvcmlnaW5hbCAN Cj4gU1JNUyBlbnRyeSBpcyB0aGUgcHJlZmVyZW5jZSBhbmQgdGhlIGFkdmVydGlzaW5nIG9y IG93bmVyIHJvdXRlci4gQW55dGhpbmcgDQo+IGVsc2UgaXMgbm90IHVzZWQuIEl0IHNlZW1z IHRvIG1lIGEgc2ltcGxlIGFsZ29yaXRobSBiYXNlZCBvbiBwcmVmZXJlbmNlIA0KPiBmaXJz dCB0aGVuIGZvbGxvd2VkIGJ5IHNvbWUgcnVsZSBvbiBzZWxlY3RpbmcgdGhlIGFkdmVydGlz aW5nIHJvdXRlciBpZiANCj4gY29uZmxpY3RzIGV4aXN0IHdpdGhpbiB0aGUgc2FtZSBwcmVm ZXJlbmNlIHdvdWxkIHdvcmsuDQo+ICANCj4gW0xlczpdIFlvdSBoYXZlIGltcGxlbWVudGVk IHRoaW5ncyBpbiBhIGNlcnRhaW4gd2F5LiBTb21lb25lIGVsc2UgbWlnaHQgDQo+IGNob29z ZSB0byBpbXBsZW1lbnQgaW4gYSBkaWZmZXJlbnQgd2F5LiBBIG5vcm1hdGl2ZSBzcGVjaWZp Y2F0aW9uIGRvZXMgbm90IA0KPiAoYW5kIHNob3VsZCBub3QpIGNvbnN0cmFpbiBhbiBpbXBs ZW1lbnRhdGlvbi4gV2hhdCBpcyBiZWluZyBpbGx1c3RyYXRlZCANCj4gaGVyZSBpcyB0aGF0 IGlmIHRoZSBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCByZXRhaW4gdGhlIHVuZGVyaXZlZCBl bnRyeSAoaW4gDQo+IHdoYXRldmVyIGludGVybmFsIGZvcm0gaXQgY2hvb3NlcykgZGlmZmVy ZW50IHJlc3VsdHMgd2lsbCBiZSBvYnRhaW5lZCANCj4gYmVjYXVzZSB0aGUgcHJlZmVyZW5j ZSBhbGdvcml0aG0gZGVwZW5kcyBvbiBjb21wYXJpbmcgdGhlIHVuZGVyaXZlZCByYW5nZXMu DQo+ICANCj4gTUE+IEkgZG8gbm90IGJlbGlldmUgdGhpcyBpcyBhYm91dCBpbXBsZW1lbnRh dGlvbi4gSXQgaXMgYWJvdXQgd2hhdCByb3V0ZXJzIA0KPiBkbyBhbmQgdGhhdCBpcyByZXNv bHV0aW9uIHBlciBwcmVmaXguIEl0IGRvZXMgbm90IG1hdHRlciBob3cgdGhlIHByZWZpeCBT SUQgDQo+IGluZm9ybWF0aW9uIGlzIGFkdmVydGlzZWQsIGluZGl2aWR1YWxseSBvciBwYXJ0 IG9mIGFuIFNSTVMgZW50cnksIGF0IHRoZSANCj4gZW5kIGl0IGlzIGFzc29jaWF0ZWQgd2l0 aCBhIHByZWZpeC4NCj4gIA0KPiAzLiAgICAgRmluYWxseSwgdGhlcmUgaXMgc29tZXRoaW5n IHdoaWNoIGhhcyBub3QgYmVlbiBhZGRyZXNzZWQgaW4gdGhlIA0KPiBzbGlkZXMuIFRoZXJl IGlzIHN0aWxsIGEgcG9zc2liaWxpdHkgb2YgY29uZmxpY3RpbmcgZW50cmllcyBhbW9uZyBT SURzIA0KPiBhZHZlcnRpc2VkIHVzaW5nIHRoZSBwcmVmaXggU0lEIHN1Yi1UTFYgd2l0aGlu IGEgUHJlZml4IFRMViAoSVMtSVMgSVAgUmVhY2ggDQo+IFRMViBvciBPU1BGIEV4dGVuZGVk IFByZWZpeCBUTFYpLiBBIHNpbXBsZSBydWxlIHNlbGVjdGluZyB0aGUgYWR2ZXJ0aXNpbmcg DQo+IHJvdXRlciBzaG91bGQgYWxzbyB3b3JrIGZpbmUgaGVyZS4NCj4gIA0KPiBbTGVzOl0g Tm8goVYgc291cmNlIG9mIGFuIGFkdmVydGlzZW1lbnQgaGFzIGJlZW4gcXVpdGUgZGVsaWJl cmF0ZWx5IA0KPiBleGNsdWRlZCBmcm9tIHRoZSBwcmVmZXJlbmNlIGFsZ29yaXRobS4gV2l0 aCByZWRpc3RyaWJ1dGlvbi9yb3V0ZSBsZWFraW5nIA0KPiB0aGUgc291cmNlIG9mIGFuIGFk dmVydGlzZW1lbnQgbWF5IGFwcGVhciB0byBiZSBkaWZmZXJlbnQgb24gZGlmZmVyZW50IA0K PiByb3V0ZXJzLSB0aGlzIHdvdWxkIHJlc3VsdCBpbiBkaWZmZXJlbnQgcmVzdWx0cyBvbiBk aWZmZXJlbnQgcm91dGVycy4NCj4gIA0KPiBNQT4gVGhlIGZvbGxvd2luZyBSRkMgaXMgc3Bl Y2lmeWluZyBhbiBvcHRpb25hbCBhdHRyaWJ1dGUgKHRoZSBJUHY0L0lQdjYgDQo+IFNvdXJj ZSBSb3V0ZXIgSUQgVExWKSB0byBlbmNvZGUgdGhlIG9yaWdpbmFsIGFkdmVydGlzaW5nIHJv dXRlciBvZiBhIA0KPiBwcmVmaXguIFRoaXMgY2FuIGJlIHVzZWQgdG8gcGVyZm9ybSBhIHNp bXBsZSBzZWxlY3Rpb24gYWxnb3JpdGhtOg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzc5NCNzZWN0aW9uLTIuMiANCj4gIA0KPiBPdGhlcndpc2UsIHdoYXQgaXMgeW91 ciBwcm9wb3NhbCBmb3IgdGhpcyBwb2ludCAoMyk/IEkgY291bGQgbm90IGZpbmQgaXQgDQo+ IGFkZHJlc3NlZCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4gIA0K PiBbTGVzMjpdIFRoZSBwcm9wb3NhbCBpcyBOT1QgdG8gdXNlIHRoZSBzb3VyY2Ugb2YgYW4g YWR2ZXJ0aXNlbWVudCBhcyBhbiANCj4gaW5wdXQgdG8gY29uZmxpY3QgcmVzb2x1dGlvbi4N Cj4gUkZDIDc3OTQgb25seSBhZGRyZXNzZXMgdGhlIGlzc3VlIGZvciBJUy1JUyBhbmQgZXZl biB0aGVuIG9ubHkgZm9yIFNJRHMgDQo+IGxlYXJuZWQgdmlhIHByZWZpeCByZWFjaGFiaWxp dHkgYWR2ZXJ0aXNlbWVudHMuIFVzZSBvZiBzb3VyY2Ugc3RpbGwgaGFzIA0KPiBjb25zaXN0 ZW5jeSBpc3N1ZXMgZm9yIFNSTVMgYWR2ZXJ0aXNlbWVudHMsIE9TUEYsIGFuZCBjYXNlcyB3 aGljaCBpbnZvbHZlIA0KPiBtdWx0aXBsZSBwcm90b2NvbCBpbnN0YW5jZXMuDQo+IFRoaXMg Y2hvaWNlIGhhcyBiZWVuIGNvbnNjaW91c2x5IG1hZGUgYW5kIGlzIGluIHBhcnQgYmFzZWQg b24gb3VyIA0KPiBleHBlcmllbmNlIHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLg0K PiAgDQo+IFRoYXQgc2FpZCwgdGhpcyBpc3N1ZSBpcyBvbmx5IHJlbGV2YW50IGlmIHlvdSBi ZWxpZXZlIGl0IGlzIA0KPiBuZWNlc3NhcnkvZGVzaXJhYmxlIHRvIHVzZSBhIHByZWZlcmVu Y2UgcnVsZSB0byBtYWtlIGEgY2hvaWNlIHdoZW4gYSANCj4gY29uZmxpY3QgZXhpc3RzLiAN Cj4gVGhlIHByb3BvbmVudHMgb2YgoadJZ25vcmWhqCBkb26hpnQgd2FudCB0byBkbyB0aGlz IKFWIHdlIHdhbnQgdG8gTk9UIHVzZSANCj4gU0lEcyB3aGljaCBhcmUgaW4gY29uZmxpY3Qu IFdlIGJlbGlldmUgdGhpcyBpcyBsZXNzIGxpa2VseSB0byBsZWFkIHRvIA0KPiBpbnRlcm9w ZXJhYmlsaXR5IHByb2JsZW1zIGFuZCBpcyBsZXNzIGxpa2VseSB0byBoYXZlIHVuZGVzaXJh YmxlIHNpZGUgDQo+IGVmZmVjdHMuIEl0IGFsc28gcHJpb3JpdGl6ZXMgZGV0ZWN0aW9uIGFu ZCByZXBvcnRpbmcgb2YgY29uZmxpY3RzLg0KPiAgDQo+ICAgIExlcw0KPiAgDQo+IFJlZ2Fy ZHMsDQo+IE11c3RhcGhhLg0KPiAgDQo+IEZyb206IExlcyBHaW5zYmVyZyAoZ2luc2Jlcmcp IFttYWlsdG86Z2luc2JlcmdAY2lzY28uY29tXSANCj4gU2VudDogRnJpZGF5LCBEZWNlbWJl ciAwOSwgMjAxNiAxOjQ5IFBNDQo+IFRvOiBBaXNzYW91aSwgTXVzdGFwaGEgKE5va2lhIC0g Q0EpIDxtdXN0YXBoYS5haXNzYW91aUBub2tpYS5jb20+OyANCj4gc3ByaW5nQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJFOiBTSUQgQ29uZmxpY3QgUmVzb2x1dGlvbjogQSBTaW1wbGVyIFBy b3Bvc2FsDQo+ICANCj4gTXVzdGFwaGEgLQ0KPiAgDQo+IEZyb206IEFpc3Nhb3VpLCBNdXN0 YXBoYSAoTm9raWEgLSBDQSkgW21haWx0bzptdXN0YXBoYS5haXNzYW91aUBub2tpYS5jb21d IA0KPiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDA5LCAyMDE2IDc6NDQgQU0NCj4gVG86IExl cyBHaW5zYmVyZyAoZ2luc2JlcmcpOyBzcHJpbmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6 IFNJRCBDb25mbGljdCBSZXNvbHV0aW9uOiBBIFNpbXBsZXIgUHJvcG9zYWwNCj4gIA0KPiBJ IGhhdmUgYSBjb3VwbGUgb2YgY29tbWVudHMgb24gdGhlIGJlbG93IHByb3Bvc2FsLg0KPiAg DQo+IDEuICAgICBSZWdhcmRpbmcgdGhlIFNSTVMgUHJlZmVyZW5jZSBTdWItVExWIGluIHNl Y3Rpb24gMy4xIG9mIHRoZSBkcmFmdC4gDQo+IEluIG1hbnkgY2FzZXMsIGEgY29uZmlndXJh dGlvbiBvbiB0aGUgcmVzb2x2aW5nIHJvdXRlciBjYW4gYXNzaWduIGEgDQo+IHByZWZlcmVu Y2UgdG8gZWFjaCBTUk1TIGluIGNhc2UgdGhlcmUgaXMgbm8gYWR2ZXJ0aXNlbWVudCBvZiB0 aGlzIHN1Yi1UTFYgDQo+IG9yIHRvIG92ZXJyaWRlIGFuIGFkdmVydGlzZWQgdmFsdWUuIEkg cHJvcG9zZSB0aGF0IHRoaXMgb3B0aW9uIGJlIGFsbG93ZWQuIA0KPiBIZXJlIGlzIGEgcHJv cG9zZWQgdXBkYXRlIHRvIHRoZSByZWxldmFudCBwYXJhZ3JhcGg6DQo+IKGnDQo+ICAgICAg ICAgICAgQWR2ZXJ0aXNlbWVudCBvZiBhIHByZWZlcmVuY2UgdmFsdWUgaXMgb3B0aW9uYWwu ICBOb2RlcyB3aGljaCBkbyANCj4gbm90DQo+ICAgICAgICAgICBhZHZlcnRpc2UgYSBwcmVm ZXJlbmNlIHZhbHVlIGFyZSBhc3NpZ25lZCBhIHByZWZlcmVuY2UgdmFsdWUgb2YgDQo+IDEy OC4gICAgICAgICAgICAgICAgICAgICAgICANCj4gICAgICAgICAgICBBIHJlc29sdmluZyBy b3V0ZXIgY2FuIG92ZXJyaWRlIHRoZSBkZWZhdWx0IG9yIHRoZSBhZHZlcnRpc2VkIA0KPiB2 YWx1ZSBieSBsb2NhbCBwb2xpY3kuDQo+IKGnDQo+IFtMZXM6XSBJbiBvcmRlciB0byBnZXQg Y29uc2lzdGVudCBjb25mbGljdCByZXNvbHV0aW9uIG9uIGFsbCBub2RlcyBpbiB0aGUgDQo+ IG5ldHdvcmssIGl0IGlzIG5lY2Vzc2FyeSB0aGF0IHRoZXkgYWxsIGhhdmUgdGhlIHNhbWUg ZGF0YWJhc2UgoVYgd2hpY2ggDQo+IGluY2x1ZGVzIHRoZSBwcmVmZXJlbmNlIHZhbHVlLiBJ ZiB5b3UgYWxsb3cgbG9jYWwgcG9saWN5IHRvIG1vZGlmeSB0aGUgDQo+IHByZWZlcmVuY2Ug eW91IG5vIGxvbmdlciBoYXZlIGNvbnNpc3RlbnQgZGF0YWJhc2VzIG9uIGFsbCBub2RlcyBh bmQgd2UgY2FuIA0KPiBubyBsb25nZXIgZ3VhcmFudGVlIGNvbnNpc3RlbnQgY29uZmxpY3Qg cmVzb2x1dGlvbi4gU28geW91ciBwcm9wb3NhbCBpcyBub3QgDQo+IHZpYWJsZSBJTU8uDQo+ ICANCj4gMi4gICAgIEkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIGNvbmNlcHQgb2Yg c29ydGluZyBTUk1TIGVudHJpZXMgd2hpY2ggDQo+IGhhdmUgZGlmZmVyZW50IHByZWZpeGVz IGFuZCBkaWZmZXJlbnQgcmFuZ2Ugc2l6ZXMuICANCj4gU2luY2UgYSBTSUQgYWR2ZXJ0aXNl ZCBpbiBhIHByZWZpeCBTSUQgc3ViLVRMViB3aXRoaW4gYSBQcmVmaXggVExWIChJUy1JUyAN Cj4gSVAgUmVhY2ggVExWIG9yIE9TUEYgRXh0ZW5kZWQgUHJlZml4IFRMVikgaGFzIGhpZ2hl ciBwcmlvcml0eSBvdmVyIGEgU0lEIA0KPiBmb3IgdGhlIHNhbWUgcHJlZml4IGFkdmVydGlz ZWQgZnJvbSBhIFNSTVMsIHRoZW4geW91IGhhdmUgdG8gYWRkIHRvIHRoZSANCj4gYmVsb3cg c29ydGluZyBhbiBlbnRyeSBmb3IgZWFjaCBpbmRpdmlkdWFsIHByZWZpeCB3aGljaCBhZHZl cnRpc2VkIGEgcHJlZml4IA0KPiBTSUQgc3ViLVRMViB3aXRoaW4gYSBwcmVmaXggVExWLiAN Cj4gQXQgdGhpcyBwb2ludCwgdGhlIGNvbmNlcHQgb2YgYW4gZW50cnkgd2l0aCBtdWx0aXBs ZSBwcmVmaXhlcyBpcyBtb290IGFuZCANCj4geW91IG1heSBhcyB3ZWxsIGp1c3Qgc29ydCBv biBhIHBlciBwcmVmaXggYmFzaXMgd2hpY2ggaXMgdGhlIG1vc3QgbmF0dXJhbCANCj4gdGhp bmcgdG8gZG8gZ2l2ZW4gdGhhdCB0aGUgcHJlZml4IHJlc29sdXRpb24gYW5kIHRoZW4gdGhl IFNJRCByZXNvbHV0aW9uIA0KPiBhcmUgcGVyZm9ybWVkIG9uIGEgcGVyIHByZWZpeCBiYXNp cy4gU0lEIGNvbmZsaWN0cyBjYW4gYmUgcmVzb2x2ZWQgb24gYSBwZXIgDQo+IHByZWZpeCBi YXNpcyB1c2luZyB0aGUgYmVsb3cgcHJvcG9zZWQgcHJlZmVyZW5jZSBhbGdvcml0aG0gd2l0 aG91dCBoYXZpbmcgDQo+IHRvIGlnbm9yZSBTSUQgdmFsdWVzIGZvciB1bnJlbGF0ZWQgcHJl Zml4ZXMganVzdCBiZWNhdXNlIGl0IGhhcHBlbnMgdGhhdCANCj4gdGhleSB3ZXJlIGFkdmVy dGlzZWQgaW4gdGhlIHNhbWUgU1JNUyBlbnRyeS4NCj4gIA0KPiBbTGVzOl0gVGhlIHNpbXBs ZXIgcHJvcG9zYWwgZG9lcyBub3QgcmVxdWlyZSBzb3J0aW5nIG9uIGFueXRoaW5nIG90aGVy IHRoYW4gDQo+IHByZWZlcmVuY2UuIEFmdGVyIHRoYXQsIHlvdSBjYW4gcHJvY2VzcyBlbnRy aWVzIGluIGFueSBvcmRlciB5b3Ugd2FudCBhbmQgDQo+IHlvdSB3aWxsIGdldCB0aGUgc2Ft ZSBhbnN3ZXIuDQo+IFdpdGggoadJZ25vcmUgT3ZlcmxhcCBPbmx5oaggb25lIG9mIHRoZSBp c3N1ZXMgd2l0aCB0cnlpbmcgdG8gdXNlIHRoZSANCj4gbm9uLWNvbmZsaWN0aW5nIHBvcnRp b25zIG9mIGEgbWFwcGluZyBlbnRyeSB3aGljaCBoYXMgYSByYW5nZSA+IDEgaXMgdGhhdCAN Cj4gdGhlIG9yZGVyIGluIHdoaWNoIHlvdSBwcm9jZXNzIGVudHJpZXMgaW5mbHVlbmNlcyB0 aGUgcmVzdWx0LiBQbGVhc2Ugc2VlIA0KPiBzbGlkZXMgMTcgoVYgMjAgZnJvbSB0aGUgSUVU Rjk3IHByZXNlbnRhdGlvbjogDQo+IA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1zcHJpbmctMV9pZXRmOTdfZHJhZnQtaWV0Zi1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbi0wMi0wMC5wcHR4IA0KPiBmb3Igc29tZSBzaW1wbGUg ZXhhbXBsZXMgb2YgdGhpcy4NCj4gIA0KPiAgICBMZXMNCj4gIA0KPiAgDQo+IFJlZ2FyZHMs DQo+IE11c3RhcGhhLg0KPiAgDQo+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVzIEdpbnNiZXJnIA0KPiAoZ2luc2Jlcmcp DQo+IFNlbnQ6IFN1bmRheSwgRGVjZW1iZXIgMDQsIDIwMTYgNzowNCBQTQ0KPiBUbzogc3By aW5nQGlldGYub3JnDQo+IFN1YmplY3Q6IFtzcHJpbmddIFNJRCBDb25mbGljdCBSZXNvbHV0 aW9uOiBBIFNpbXBsZXIgUHJvcG9zYWwNCj4gIA0KPiBXaGVuIHRoZSBwcm9ibGVtIGFkZHJl c3NlZCBieSBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIHdhcyANCj4g Zmlyc3QgDQo+IHByZXNlbnRlZCBhdCBJRVRGIDk0LCB0aGUgYXV0aG9ycyBkZWZpbmVkIHRo ZSBmb2xsb3dpbmcgcHJpb3JpdGllczoNCj4gIA0KPiAxKURldGVjdCB0aGUgcHJvYmxlbQ0K PiAyKVJlcG9ydCB0aGUgcHJvYmxlbQ0KPiBUaGlzIGFsZXJ0cyB0aGUgbmV0d29yayBvcGVy YXRvciB0byB0aGUgZXhpc3RlbmNlIG9mIGEgY29uZmxpY3Qgc28gdGhhdA0KPiB0aGUgY29u ZmlndXJhdGlvbiBlcnJvciBjYW4gYmUgY29ycmVjdGVkLg0KPiAzKURlZmluZSBjb25zaXN0 ZW50IGJlaGF2aW9yDQo+IFRoaXMgYXZvaWRzIG1pcy1mb3J3YXJkaW5nIHdoaWxlIHRoZSBj b25mbGljdCBleGlzdHMuDQo+IDQpRG9uoaZ0IG92ZXJlbmdpbmVlciB0aGUgc29sdXRpb24N Cj4gR2l2ZW4gdGhhdCBpdCBpcyBpbXBvc3NpYmxlIHRvIGtub3cgd2hpY2ggb2YgdGhlIGNv bmZsaWN0aW5nIGVudHJpZXMNCj4gaXMgdGhlIGNvcnJlY3Qgb25lLCB3ZSBzaG91bGQgYXBw bHkgYSBzaW1wbGUgYWxnb3JpdGhtIHRvIHJlc29sdmUgdGhlIA0KPiBjb25mbGljdC4NCj4g NSlBZ3JlZSBvbiB0aGUgcmVzb2x1dGlvbiBiZWhhdmlvcg0KPiAgDQo+IFRoZSByZXNvbHV0 aW9uIGJlaGF2aW9yIHdhcyBkZWxpYmVyYXRlbHkgdGhlIGxhc3QgcG9pbnQgYmVjYXVzZSBp dCB3YXMgDQo+IGNvbnNpZGVyZWQgdGhlIGxlYXN0IGltcG9ydGFudC4NCj4gIA0KPiBJbnB1 dCB3YXMgcmVjZWl2ZWQgb3ZlciB0aGUgcGFzdCB5ZWFyIHdoaWNoIGVtcGhhc2l6ZWQgdGhl IGltcG9ydGFuY2Ugb2YNCj4gdHJ5aW5nIHRvICJtYXhpbWl6ZSBmb3J3YXJkaW5nIiBpbiB0 aGUgcHJlc2VuY2Ugb2YgY29uZmxpY3RzLiBTdWJzZXF1ZW50DQo+IHJldmlzaW9ucyBvZiB0 aGUgZHJhZnQgaGF2ZSB0cmllZCB0byBhZGRyZXNzIHRoaXMgY29uY2Vybi4gSG93ZXZlciB0 aGUgDQo+IGF1dGhvcnMgDQo+IGhhdmUgcmVwZWF0ZWRseSBzdHJlc3NlZCB0aGF0IHRoZSBz b2x1dGlvbiBiZWluZyBwcm9wb3NlZCANCj4gKCJpZ25vcmUgb3ZlcmxhcCBvbmx5Iikgd2Fz IG1vcmUgY29tcGxleCB0aGFuIG90aGVyIG9mZmVyZWQgYWx0ZXJuYXRpdmVzIA0KPiBhbmQg DQo+IHdvdWxkIGJlIG1vcmUgZGlmZmljdWx0IHRvIGd1YXJhbnRlZSBpbnRlcm9wZXJhYmls aXR5IGJlY2F1c2Ugc3VidGxlIA0KPiBkaWZmZXJlbmNlcyBpbiBhbiBpbXBsZW1lbnRhdGlv biBjb3VsZCBwcm9kdWNlIGRpZmZlcmVudCByZXN1bHRzLg0KPiAgDQo+IEF0IElFVEY5NyBz aWduaWZpY2FudCBmZWVkYmFjayB3YXMgcmVjZWl2ZWQgcHJlZmVycmluZyBhIHNpbXBsZXIg c29sdXRpb24gDQo+IHRvIA0KPiB0aGUgcHJvYmxlbS4gVGhlIGF1dGhvcnMgYXJlIHZlcnkg c3ltcGF0aGV0aWMgdG8gdGhpcyBmZWVkYmFjayBhbmQgDQo+IHRoZXJlZm9yZSANCj4gYXJl IHByb3Bvc2luZyBhIHNvbHV0aW9uIGJhc2VkIG9uIHdoYXQgdGhlIGRyYWZ0IGRlZmluZXMg YXMgdGhlICJJZ25vcmUiIA0KPiBwb2xpY3kgLSB3aGVyZSBhbGwgZW50cmllcyB3aGljaCBh cmUgaW4gY29uZmxpY3QgYXJlIGlnbm9yZWQuIFdlIGJlbGlldmUgDQo+IHRoaXMgDQo+IGlz IGZhciBtb3JlIGRlc2lyYWJsZSBhbmQgYWxpZ25zIHdpdGggdGhlIHByaW9yaXRpZXMgbGlz dGVkIGFib3ZlLg0KPiAgDQo+IFdlIG91dGxpbmUgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGJl bG93IGFuZCB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgZmVlZGJhY2sgDQo+IGZyb20gDQo+IHRo ZSBXRyBiZWZvcmUgcHVibGlzaGluZyB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQu DQo+ICANCj4gICAgTGVzIChvbiBiZWhhbGYgb2YgdGhlIGF1dGhvcnMpDQo+ICANCj4gTmV3 IFByb3Bvc2FsDQo+ICANCj4gSW4gdGhlIGxhdGVzdCByZXZpc2lvbiBvZiB0aGUgZHJhZnQg IlNSTVMgUHJlZmVyZW5jZSIgd2FzIGludHJvZHVjZWQuIFRoaXMgDQo+IHByb3ZpZGVzIGEg d2F5IGZvciBhIG51bWVyaWNhbCBwcmVmZXJlbmNlIHRvIGJlIGV4cGxpY2l0bHkgYXNzb2Np YXRlZCB3aXRoIA0KPiBhbiANCj4gU1JNUyBhZHZlcnRpc2VtZW50LiBVc2luZyB0aGlzIGFu IG9wZXJhdG9yIGNhbiBpbmRpY2F0ZSB3aGljaCBhZHZlcnRpc2VtZW50IA0KPiBpcyANCj4g dG8gYmUgcHJlZmVycmVkIHdoZW4gYSBjb25mbGljdCBpcyBwcmVzZW50LiBUaGUgYXV0aG9y cyB0aGluayB0aGlzIGlzIGEgDQo+IHVzZWZ1bCANCj4gYWRkaXRpb24gYW5kIHdlIHRoZXJl Zm9yZSB3YW50IHRvIGluY2x1ZGUgdGhpcyBpbiB0aGUgbmV3IHNvbHV0aW9uLg0KPiAgDQo+ IFRoZSBuZXcgcHJlZmVyZW5jZSBydWxlIHVzZWQgdG8gcmVzb2x2ZSBjb25mbGljdHMgaXMg ZGVmaW5lZCBhcyBmb2xsb3dzOg0KPiAgDQo+IEEgZ2l2ZW4gbWFwcGluZyBlbnRyeSBpcyBj b21wYXJlZCBhZ2FpbnN0IGFsbCBtYXBwaW5nIGVudHJpZXMgaW4gdGhlIA0KPiBkYXRhYmFz ZSANCj4gd2l0aCBhIHByZWZlcmVuY2UgZ3JlYXRlciB0aGFuIG9yIGVxdWFsIHRvIGl0cyBv d24uIElmIHRoZXJlIGlzIGEgY29uZmxpY3QsIA0KPiB0aGUgbWFwcGluZyBlbnRyeSB3aXRo IGxvd2VyIHByZWZlcmVuY2UgaXMgaWdub3JlZC4gSWYgdHdvIG1hcHBpbmcgZW50cmllcyAN Cj4gYXJlDQo+IGluIGNvbmZsaWN0IGFuZCBoYXZlIGVxdWFsIHByZWZlcmVuY2UgdGhlbiBi b3RoIGVudHJpZXMgYXJlIGlnbm9yZWQuDQo+ICANCj4gSW1wbGVtZW50YXRpb24gb2YgdGhp cyBwb2xpY3kgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOg0KPiAgDQo+IFN0ZXAgMTogV2l0aGlu IGEgc2luZ2xlIGFkZHJlc3MtZmFtaWx5L2FsZ29yaXRobS90b3BvbG9neSBzb3J0IGVudHJp ZXMgDQo+IGJhc2VkIG9uIHByZWZlcmVuY2UgDQo+IFN0ZXAgMjogU3RhcnRpbmcgd2l0aCB0 aGUgbG93ZXN0IHByZWZlcmVuY2UgZW50cmllcywgcmVzb2x2ZSBwcmVmaXggDQo+IGNvbmZs aWN0cyANCj4gdXNpbmcgdGhlIGFib3ZlIHByZWZlcmVuY2UgcnVsZS4gVGhlIG91dHB1dCBp cyBhbiBhY3RpdmUgcG9saWN5IHBlciANCj4gdG9wb2xvZ3kuDQo+IFN0ZXAgMzogVGFrZSB0 aGUgb3V0cHV0cyBmcm9tIFN0ZXAgMiBhbmQgYWdhaW4gc29ydCB0aGVtIGJ5IHByZWZlcmVu Y2UgDQo+IFN0ZXAgNDogU3RhcnRpbmcgd2l0aCB0aGUgbG93ZXN0IHByZWZlcmVuY2UgZW50 cmllcywgcmVzb2x2ZSBTSUQgY29uZmxpY3RzIA0KPiB1c2luZyB0aGUgYWJvdmUgcHJlZmVy ZW5jZSBydWxlDQo+ICANCj4gVGhlIG91dHB1dCBmcm9tIFN0ZXAgNCBpcyB0aGVuIHRoZSBj dXJyZW50IEFjdGl2ZSBQb2xpY3kuDQo+ICANCj4gSGVyZSBhcmUgYSBmZXcgZXhhbXBsZXMu IEVhY2ggbWFwcGluZyBlbnRyeSBpcyByZXByZXNlbnRlZCBieSB0aGUgdHVwbGU6DQo+IChQ cmVmZXJlbmNlLCBQcmVmaXgvbWFzayBJbmRleCByYW5nZSA8Iz4pDQo+ICANCj4gRXhhbXBs ZSAxOg0KPiAgDQo+IDEuICgxNTAsIDEuMS4xLjEvMzIgMTAwIHJhbmdlIDEwMCkNCj4gMi4g KDE0OSwgMS4xLjEuMTAvMzIgMjAwIHJhbmdlIDIwMCkNCj4gMy4gKDE0OCwgMS4xLjEuMTAx LzMyIDUwMCByYW5nZSAxMCkNCj4gIA0KPiBFbnRyeSAzIGNvbmZsaWN0cyB3aXRoIGVudHJ5 IDIsIGl0IGlzIGlnbm9yZWQuDQo+IEVudHJ5IDIgY29uZmxpY3RzIHdpdGggZW50cnkgMSwg aXQgaXMgaWdub3JlZC4NCj4gQWN0aXZlIHBvbGljeToNCj4gIA0KPiAoMTUwLCAxLjEuMS4x LzMyIDEwMCByYW5nZSAxMDApDQo+ICANCj4gRXhhbXBsZSAyOg0KPiAgDQo+IDEuICgxNTAs IDEuMS4xLjEvMzIgMTAwIHJhbmdlIDEwMCkNCj4gMi4gKDE1MCwgMS4xLjEuMTAvMzIgMjAw IHJhbmdlIDIwMCkNCj4gMy4gKDE1MCwgMS4xLjEuMTAxLzMyIDUwMCByYW5nZSAxMCkNCj4g NC4gKDE1MCwgMi4yLjIuMS8zMiAxMDAwIHJhbmdlIDEpDQo+ICANCj4gRW50cnkgMSBjb25m bGljdHMgd2l0aCBlbnRyeSAyLCBib3RoIGFyZSBtYXJrZWQgYXMgaWdub3JlLg0KPiBFbnRy eSAzIGNvbmZsaWN0cyB3aXRoIGVudHJ5IDIuIEl0IGlzIG1hcmtlZCBhcyBpZ25vcmUuDQo+ IEVudHJ5IDQgaGFzIG5vIGNvbmZsaWN0cyB3aXRoIGFueSBlbnRyaWVzDQo+ICANCj4gQWN0 aXZlIHBvbGljeToNCj4gKDE1MCwgMi4yLjIuMS8zMiAxMDAwIHJhbmdlIDEpDQo+ICANCj4g RXhhbXBsZSAzOg0KPiAgDQo+IDEuICgxNTAsIDEuMS4xLjEvMzIgMTAwIHJhbmdlIDUwMCkN Cj4gMi4gKDE1MCwgMS4xLjEuMTAvMzIgMjAwIHJhbmdlIDIwMCkNCj4gMy4gKDE1MCwgMS4x LjEuMTAxLzMyIDUwMCByYW5nZSAxMCkNCj4gNC4gKDE1MCwgMi4yLjIuMS8zMiAxMDAwIHJh bmdlIDEpDQo+ICANCj4gRW50cnkgMSBjb25mbGljdHMgd2l0aCBlbnRyaWVzIDIsIDMsIGFu ZCAgNC4gQWxsIGVudHJpZXMgYXJlIG1hcmtlZCBpZ25vcmUuDQo+ICANCj4gQWN0aXZlIHBv bGljeToNCj4gRW1wdHkNCj4gIA0KPiBFeGFtcGxlIDQ6DQo+ICANCj4gMS4gKDE1MCwgMS4x LjEuMS8zMiAxMDAgcmFuZ2UgMTApDQo+IDIuICgxNDksIDEuMS4xLjEwLzMyIDIwMCByYW5n ZSAzMDApDQo+IDMuICgxNDksIDEuMS4xLjEwMS8zMiA1MDAgcmFuZ2UgMTApDQo+IDQuICgx NDgsIDIuMi4yLjEvMzIgMTAwMCByYW5nZSAxKQ0KPiAgDQo+IEVudHJ5IDQgY29uZmxpY3Rz IHdpdGggZW50cnkgMi4gSXQgaXMgbWFya2VkIGlnbm9yZS4NCj4gRW50cnkgMiBjb25mbGlj dHMgd2l0aCBlbnRyeSAzLiBFbnRyaWVzIDIgYW5kIDMgYXJlIG1hcmtlZCBpZ25vcmUuDQo+ ICANCj4gQWN0aXZlIHBvbGljeToNCj4gKDE1MCwgMS4xLjEuMS8zMiAxMDAgcmFuZ2UgMTAp DQo+ICANCj4gIA0KPiAgDQo+ICANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gc3ByaW5n QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5n From nobody Mon Jan 2 07:05:28 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 23F5012962D; Mon, 2 Jan 2017 07:05:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148336952414.21936.16514454478632951112.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2017 07:05:24 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-sr-oam-requirement-03.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 15:05:24 -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 : OAM Requirements for Segment Routing Network Authors : Nagendra Kumar Carlos Pignataro Nobo Akiya Ruediger Geib Greg Mirsky Stephane Litkowski Filename : draft-ietf-spring-sr-oam-requirement-03.txt Pages : 7 Date : 2017-01-02 Abstract: This document describes a list of functional requirement for OAM in Segment Routing (SR) based network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-oam-requirement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-sr-oam-requirement-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-oam-requirement-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 5 08:42:53 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 D5116129496 for ; Thu, 5 Jan 2017 08:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, 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 KBM--E0NJbrG for ; Thu, 5 Jan 2017 08:42:47 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E651293F5 for ; Thu, 5 Jan 2017 08:42:46 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 9E59B60BA5; Thu, 5 Jan 2017 17:42:44 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 76DF160060; Thu, 5 Jan 2017 17:42:44 +0100 (CET) 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.0319.002; Thu, 5 Jan 2017 17:42:44 +0100 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: SID Conflict Resolution: A Simpler Proposal Thread-Index: AdJOibcaOvA8JiDrT2eiOTpEk40qzwDdlkBwAA8oUZACVgRskAAWou1gAtxkbWA= Date: Thu, 5 Jan 2017 16:42:43 +0000 Message-ID: <23424_1483634564_586E7784_23424_1264_1_53C29892C857584299CBF5D05346208A1ECE7974@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <84fe7b43d5054712abf09b274bc3c471@XCH-ALN-001.cisco.com> <13659_1481278031_584A824F_13659_1413_1_53C29892C857584299CBF5D05346208A1ECBEDCF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <2599_1482331179_585A942B_2599_15892_1_53C29892C857584299CBF5D05346208A1ECCA7D8@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1f3288d0ea20445389ca2dab011df9de@XCH-ALN-001.cisco.com> In-Reply-To: <1f3288d0ea20445389ca2dab011df9de@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.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ECE7974OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jan 2017 16:42:51 -0000 --_000_53C29892C857584299CBF5D05346208A1ECE7974OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Les, Thanks for the answer. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Thursday, December 22, 2016 2:50 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Bruno - From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, December 21, 2016 6:40 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Les, Still as an individual contributor, SID conflict resolution is about a trad= e-off between implementation complexity and network availability. Hence eva= luating the consequences on network availability is at least as important a= s evaluating the implementation complexity; especially as the former is eas= ier to quantify while the latter may be implementation specific. So on this= FEC/network availability standpoint, please find below three comments. 1) The slides presented might IMHO slightly mislead a reader: - the discussion on network availability compares "Quarantine" vs "Ignore O= verlap" - the conclusion discuss "Ignore Overlap" vs "Ignore" So they are comparing different things, while a quick reader may assume tha= t apples were compared to apples. Note that I'm not saying (and not thinking) that this is misleading on purp= ose. I'm expressing the way I read it. [Les:] Please remember the history here. Prior to Seoul the input we had wa= s: "Ignore" is least desirable - evaluate between "Quarantine" and "Ignore Ove= rlap". The discussion over the previous few months therefore was comparing the lat= ter two. Slides for both Berlin and Seoul were therefore prepared with that= in mind. Significant feedback at Seoul and since has made "Ignore" a candidate again= - so the email thread has now focused on "Ignore" vs "Ignore Overlap Only". If I had received this feedback before Seoul I would have prepared differen= t slides. My apologies for not being clairvoyant. :) [Bruno] My comment was related to the one set of slides presented in Seoul.= Therefore: - this set could have been self-consistent without a need for clairvoyance. - I'm not sure how much feedback received _after_ presenting those slides a= re supposed to explain why the body and the conclusion of this presentation= compare different things, without even a warning for the reader. But it's too late to change those slides. 2) Regarding the new proposal, post Seoul, it is vocal on the complexity si= de, but not on the network availability side which is not evaluated. This d= oes not helps the WG understanding of the trade-off involved and the making= of an informed decision. I'm even wondering if the network availability has been considered since by= default, this proposal seems to kill, by design, the SRMS and SR-LDP inter= -working. SRMS has been designed in order to allow for the inter-working with LDP, in= a brown-field scenario where SR is introduced in a LDP MPLS network. e.g. a typical set of advertisements would be 1. PrefixSID: (192, 1.1.1.1/32 100 range 1) 2. MS: (128, 1.1.1.1/32 100 range 255) With this simple example, not even having a configuration error but using a= nominal configuration, the MS advertisement would be ignored with the igno= re policy, hence the LDP interwork would not work, and all LDP/non-SR nodes= would loose SID hence loose SR connectivity. Eventually, you may change the algorithm, to look beyond the most preferred= entry, and check whether the SIDs are really different or not. And if not,= change the algo to pick the largest range rather than the highest preferen= ce. But this is adding complexity to cover a specific case, while keeping t= he solution weak in term of network availability, in the general case. e.g.= if we do have a different SID, many prefix (99%) would lose their SID. [Les:] Your interpretation is incorrect. There is no conflict in the exampl= e you provide - therefore no entries will be ignored (this is true no matte= r what conflict resolution strategy is chosen). The definition of conflicts can be found in Section 3.2 of the draft. Nothi= ng in this discussion proposes changes to that- and the definition of a con= flict has never been under debate. [Bruno] Good for this specific example. Thanks for spelling this detail out. This however does not answer the general comment regarding the evaluation o= f the network availability, for this new proposal. What we have discussed over the last 6 months or more has been what to do w= hen conflicts exist- this is Section 3.3 of the draft. 3) Finally, when discussing "Ignore Overlap", a typical quote from the auth= ors is "maximize forwarding" or "operate optimally", as if we were trying t= o optimize for the last bit. But note that "Ignore Overlap" is _not_ maximi= zing forwarding. Maximizing forwarding would be much more complex, and nob= ody on the list has even tried for this, including draft-ietf-spring-confli= ct-resolution. e.g. with following advertisements with a misconfiguration 1. PrefixSID: (192, 1.1.1.1/32 101 range 1) 2. MS: (128, 1.1.1.1/32 100 range 255) During prefix conflict, for 1.1.1.1/32 Ignore Overlap selects the SID from = prefixSID entry, which will latter have a SID conflict with the MS entry (S= ID 101, prefixes 1.1.1.1 vs 1.1.1.2). As a result, 1.1.1.2 won't get a SID. In this specific case, a solution "maximizing the forwarding" would have ig= nored the PrefixSID. But in the general case, "maximizing the forwarding" m= ay require evaluating all options, and then pick the best one based on all = results. So please let's keep evaluating the impact on the network availability. Ber= lin presentation was a good example on this. [Les:] Well, the Berlin slides (see Slide 25) use the term "Maximize SR For= warding". https://www.ietf.org/proceedings/96/slides/slides-96-spring-4.pdf One of the problems with making a choice when conflicts exist is that there= is no way of knowing what prefixes are the most important in a particular = network deployment. [Bruno] Relative importance of prefix is completely orthogonal. So far, all= evaluations have been made by counting the number of prefixes disregarded.= Let's continue this way. I'm not sure why you want to make the evaluation = more complex. "Ignore overlap only" aimed to maximize the number of prefixes which had S= IDs [Bruno] I'd say "improve" rather than "maximize" the number of SIDs. Otherw= ise, that goal is missed, as highlighted in my examepl. in the hope that we would have a greater chance of including the more impor= tant prefixes [Bruno] again, relative importance of prefixes have not been consider nor d= iscuss. - but since all of our tie-breakers are simply arbitrary choices there is n= o guarantee. From Section 3.3.4 of the draft: 2 Smaller range wins 3. IPv6 entry wins over IPv4 entry 4. Longer prefix length wins 5. Smaller algorithm wins 6. Smaller starting address (considered as an unsigned integer value) wins 7. Smaller starting SID wins If you were to seriously try to focus on "network availability" we would ne= ed to incorporate additional information which might include: =B7 Is a prefix reachable? =B7 How much traffic depends on each prefix =B7 What class of traffic depends on each prefix [Bruno] I guess it depends on how we define "network availability". We can = rephrase as PE/FEC availability if you want. And yes, network operator are serious about network availability. I'd assum= e that box vendor are serious about box availability. This can only increase the complexity of the implementation - and I have no= doubt the debate about the best heuristics could go on without end. [Bruno] I'm not asking for maximizing the PE/FEC availability. I'm asking f= or not using the term "maximizing", since this is not what we are looking f= or (nor doing). I return again to the priorities which the authors stated from the beginnin= g: 1)Detect the problem 2)Report the problem 3)Define consistent behavior 4)Don't overengineer the solution Given that it is impossible to know which of the conflicting entries is the correct one, we should apply a simple algorithm to resolve the confl= ict. 5)Agree on the resolution behavior For some of us, the resolution behavior is the least important. For you it = seems it is the most important. [Bruno] We all agree on points 1 to 3 so there is no need to discuss them. What is important is the end result for the users of the network. And that'= s not even in the authors list of priority, even after two years of discuss= ion and statements from multiple network operators that this point it impor= tant. --Bruno That is what the debate is really about. Les --Bruno From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, December 09, 2016 7:31 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Bruno - Welcome back to the discussion. :) Inline. From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, December 09, 2016 2:07 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Hi Les, As a individual contributor, please find below some clarification questions= [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Monday, December 05, 2016 1:04 AM To: spring@ietf.org Subject: [spring] SID Conflict Resolution: A Simpler Proposal When the problem addressed by draft-ietf-spring-conflict-resolution was fir= st presented at IETF 94, the authors defined the following priorities: 1)Detect the problem 2)Report the problem This alerts the network operator to the existence of a conflict so that the configuration error can be corrected. 3)Define consistent behavior This avoids mis-forwarding while the conflict exists. 4)Don't overengineer the solution Given that it is impossible to know which of the conflicting entries is the correct one, we should apply a simple algorithm to resolve the confl= ict. 5)Agree on the resolution behavior The resolution behavior was deliberately the last point because it was considered the least important. Input was received over the past year which emphasized the importance of trying to "maximize forwarding" in the presence of conflicts. Subsequent revisions of the draft have tried to address this concern. However the auth= ors have repeatedly stressed that the solution being proposed ("ignore overlap only") was more complex than other offered alternatives and would be more difficult to guarantee interoperability because subtle differences in an implementation could produce different results. At IETF97 significant feedback was received preferring a simpler solution to the problem. The authors are very sympathetic to this feedback and therefore are proposing a solution based on what the draft defines as the "Ignore" policy - where all entries which are in conflict are ignored. We believe th= is is far more desirable and aligns with the priorities listed above. [Bruno] In the draft, the "Ignore" policy (=A73.3.1) ignores all conflictin= g entries. In your below proposition, the policy seems to pick the most preferred entr= y. This looks like more similar to the "Quarantine" policy proposed in the = draft (=A73.3.2) Am I missing something? [Les:] At the time "Ignore" was introduced (over a year ago) the notion of = "SRMS preference" did not exist - that was only added in the most recent ve= rsion of the draft. We (the authors) feel that this is a useful construct because: 1)It provides an explicit basis on which to choose between conflicting entr= ies. 2)It is particularly useful when bringing up a new SRMS as it allows the ad= vertised values to be verified before they are used. So, your comment is correct in that there is now a preference algorithm in = use - whereas with the original definition of "Ignore" there was no prefere= nce algorithm. But the sole criteria of the preference rule is the explicit= ly configured preference - none of the other criteria proposed for Quaranti= ne are used - and in particular we do not make partial use of a mapping ent= ry as is the case with "Ignore Overlap Only". I am happy to modify the nomenclature - but the point of this thread is not= to replace a new draft revision - it is to get the sense of the WG before = we publish a new revision as to whether we should continue down the "Ignore= Overlap only" path or move to a simpler strategy - so let's not be too pic= ky about the naming. We outline the proposed solution below and would like to receive feedback f= rom the WG before publishing the next revision of the draft. Les (on behalf of the authors) New Proposal In the latest revision of the draft "SRMS Preference" was introduced. This provides a way for a numerical preference to be explicitly associated with = an SRMS advertisement. Using this an operator can indicate which advertisement= is to be preferred when a conflict is present. The authors think this is a use= ful addition and we therefore want to include this in the new solution. The new preference rule used to resolve conflicts is defined as follows: A given mapping entry is compared against all mapping entries in the databa= se with a preference greater than or equal to its own. If there is a conflict, the mapping entry with lower preference is ignored. If two mapping entries = are in conflict and have equal preference then both entries are ignored. Implementation of this policy is defined as follows: Step 1: Within a single address-family/algorithm/topology sort entries based on preference [Bruno] I'm not sure what you are refering to by "preference". Is this the = IGP "SRMS Preference sub-TLV" or is this the preference defined in the draf= t (=A73.3.4)? [Les:] It is the former. Assuming you meant the SRMS preference, why limiting to this field, rather = than including all fields defined in the draft preference algo? Using the latter would reduce the risk of ignoring all entries (i.e. having= no entry in output of this algo). Also a priori, a sort would not be requ= ired as a single pass could select the most preferred entry. [Les:] The point of the alternative proposal is a simplification. The prese= ntation in Seoul (check out the slides) highlighted complexities in the imp= lementation of "ignore-overlap-only" - in particular subtleties in the orde= r in which an implementation looks at entries which could produce interoper= ability issues even though implementations are using the same preference ru= le. The alternative reduces the chances of these interoperability issues oc= curring because the algorithm used is simpler and less subject to subtle im= plementation differences. If you want to argue that these are solvable problems I won't disagree with= you - it is a question of where we want to put our time and effort. A numb= er of folks are commenting that they prefer to focus on fixing the configur= ation and not invest time in validating that conflict resolution is implem= ented in an interoperable way. As we (the authors) have stated from the beg= inning, we believe the emphasis should be on detecting and reporting the co= nflicts - not spending cycles implementing the most robust means of trying = to operate optimally while the misconfiguration exists. I know you disagree= on this point - but that is exactly what the WG is debating - not whether = it is possible to make "ignore overlap only" work. Les Thanks -- Bruno Step 2: Starting with the lowest preference entries, resolve prefix conflic= ts using the above preference rule. The output is an active policy per topolog= y. Step 3: Take the outputs from Step 2 and again sort them by preference Step 4: Starting with the lowest preference entries, resolve SID conflicts using the above preference rule The output from Step 4 is then the current Active Policy. Here are a few examples. Each mapping entry is represented by the tuple: (Preference, Prefix/mask Index range <#>) Example 1: 1. (150, 1.1.1.1/32 100 range 100) 2. (149, 1.1.1.10/32 200 range 200) 3. (148, 1.1.1.101/32 500 range 10) Entry 3 conflicts with entry 2, it is ignored. Entry 2 conflicts with entry 1, it is ignored. Active policy: (150, 1.1.1.1/32 100 range 100) Example 2: 1. (150, 1.1.1.1/32 100 range 100) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entry 2, both are marked as ignore. Entry 3 conflicts with entry 2. It is marked as ignore. Entry 4 has no conflicts with any entries Active policy: (150, 2.2.2.1/32 1000 range 1) Example 3: 1. (150, 1.1.1.1/32 100 range 500) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entries 2, 3, and 4. All entries are marked ignore. Active policy: Empty Example 4: 1. (150, 1.1.1.1/32 100 range 10) 2. (149, 1.1.1.10/32 200 range 300) 3. (149, 1.1.1.101/32 500 range 10) 4. (148, 2.2.2.1/32 1000 range 1) Entry 4 conflicts with entry 2. It is marked ignore. Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore. Active policy: (150, 1.1.1.1/32 100 range 10) ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ECE7974OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Les,

 

Thanks for the answer.

Please see inline [Bruno]

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.c= om]
Sent: Thursday, December 22, 2016 2:50 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

Bruno -=

&n= bsp;

From: bruno.decraene@orange.com [ma= ilto:bruno.decraene@orange.com]
Sent: Wednesday, December 21, 2016 6:40 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

Les,

&n= bsp;

Still a= s an individual contributor, SID conflict resolution is about a trade-off b= etween implementation complexity and network availability. Hence evaluating= the consequences on network availability is at least as important as evaluating the implementation complexity; espe= cially as the former is easier to quantify while the latter may be implemen= tation specific. So on this FEC/network availability standpoint, please fin= d below three comments.

&n= bsp;

1) The = slides presented might IMHO slightly mislead a reader:

- the d= iscussion on network availability compares "Quarantine" vs "= Ignore Overlap"

- the c= onclusion discuss "Ignore Overlap" vs "Ignore"

&n= bsp;

So they= are comparing different things, while a quick reader may assume that apple= s were compared to apples.

Note th= at I'm not saying (and not thinking) that this is misleading on purpose. I'= m expressing the way I read it.

&n= bsp;

[= Les:] Please remember the history here. Prior to Seoul the input we had was= :

&= #8220;Ignore” is least desirable – evaluate between “Quar= antine” and “Ignore Overlap”.

T= he discussion over the previous few months therefore was comparing the latt= er two. Slides for both Berlin and Seoul were therefore prepared with that = in mind.

<= o:p> 

S= ignificant feedback at Seoul and since has made “Ignore” a cand= idate again – so the email thread has now focused on “Ignore= 221; vs “Ignore Overlap Only”.

I= f I had received this feedback before Seoul I would have prepared different= slides.

<= o:p> 

M= y apologies for not being clairvoyant. J<= o:p>

&n= bsp;

[Bruno] My comment was related = to the one set of slides presented in Seoul. Therefore:

- this set could have been self= -consistent without a need for clairvoyance.

- I’m not sure how much f= eedback received _after_ presenting those slides are supposed to exp= lain why the body and the conclusion of this presentation compare different= things, without even a warning for the reader.

But it’s too late to chan= ge those slides.

&n= bsp;

2) Rega= rding the new proposal, post Seoul, it is vocal on the complexity side, but= not on the network availability side which is not evaluated. This does not= helps the WG understanding of the trade-off involved and the making of an informed decision.

I'm eve= n wondering if the network availability has been considered since by defaul= t, this proposal seems to kill, by design, the SRMS and SR-LDP inter-workin= g.

SRMS ha= s been designed in order to allow for the inter-working with LDP, in a brow= n-field scenario where SR is introduced in a LDP MPLS network.

e.g. a = typical set of advertisements would be

1. Pref= ixSID: (192, 1.1.1.1/32 100 range 1)

2. MS: =        (128, 1.1.1.1/32 100 range 255)

&n= bsp;

With th= is simple example, not even having a configuration error but using a nomina= l configuration, the MS advertisement would be ignored with the ignore poli= cy, hence the LDP interwork would not work, and all LDP/non-SR nodes would loose SID hence loose SR connectivity= .

Eventua= lly, you may change the algorithm, to look beyond the most preferred entry,= and check whether the SIDs are really different or not. And if not, change= the algo to pick the largest range rather than the highest preference. But this is adding complexity to cover a spec= ific case, while keeping the solution weak in term of network availability,= in the general case. e.g. if we do have a different SID, many  prefix= (99%) would lose their SID.

&n= bsp;

[= Les:] Your interpretation is incorrect. There is no conflict in the example= you provide – therefore no entries will be ignored (this is true no = matter what conflict resolution strategy is chosen).

T= he definition of conflicts can be found in Section 3.2 of the draft. Nothin= g in this discussion proposes changes to that- and the definition of a conf= lict has never been under debate.

[Bruno] Good for this specific = example. Thanks for spelling this detail out.

This however does not answer th= e general comment regarding the evaluation of the network availability, for= this new proposal.

<= o:p> 

W= hat we have discussed over the last 6 months or more has been what to do wh= en conflicts exist- this is Section 3.3 of the draft.=

<= o:p> 

&n= bsp;

&n= bsp;

3) Fina= lly, when discussing "Ignore Overlap", a typical quote from the a= uthors is "maximize forwarding" or "operate optimally",= as if we were trying to optimize for the last bit. But note that "Ign= ore Overlap" is _not_ maximizing forwarding.  Maximizing forwarding = would be much more complex, and nobody on the list has even tried for this,= including draft-ietf-spring-conflict-resolution.

e.g. wi= th following advertisements with a misconfiguration

1. Pref= ixSID: (192, 1.1.1.1/32 101 range 1)

2. MS:&= nbsp;       (128, 1.1.1.1/32 100 range 255)

&n= bsp;

During = prefix conflict, for 1.1.1.1/32 Ignore Overlap selects the SID from prefixS= ID entry, which will latter have a SID conflict with the MS entry (SID 101,= prefixes 1.1.1.1 vs 1.1.1.2). As a result, 1.1.1.2 won't get a SID.

In this= specific case, a solution "maximizing the forwarding" would have= ignored the PrefixSID. But in the general case, "maximizing the forwa= rding" may require evaluating all options, and then pick the best one based on all results.

&n= bsp;

&n= bsp;

So plea= se let’s keep evaluating the impact on the network availability. Berl= in presentation was a good example on this.

[= Les:] Well, the Berlin slides (see Slide 25) use the term “Maximize S= R Forwarding”.

https://www.ietf.org/p= roceedings/96/slides/slides-96-spring-4.pdf

<= o:p> 

<= o:p> 

O= ne of the problems with making a choice when conflicts exist is that there = is no way of knowing what prefixes are the most important in a particular n= etwork deployment.

[Bruno] Relative importance of = prefix is completely orthogonal. So far, all evaluations have been made by = counting the number of prefixes disregarded. Let’s continue this way.= I’m not sure why you want to make the evaluation more complex.

<= o:p> 

&= nbsp;“Ignore overlap only” aimed to maximize the number of pref= ixes which had SIDs

[Bruno] I’d say “im= prove” rather than “maximize” the number of SIDs. Otherwi= se, that goal is missed, as highlighted in my examepl.

<= o:p> 

i= n the hope that we would have a greater chance of including the more import= ant prefixes

[Bruno] again, relative importa= nce of prefixes have not been consider nor discuss.

&= #8211; but since all of our tie-breakers are simply arbitrary choices there= is no guarantee. From Section 3.3.4 of the draft:

<= o:p> 

2 Smaller range wins

3.  IPv6 entry wins over IPv4 entry

4.  Longer prefix length wins<= /p>

5.  Smaller algorithm wins

6.  Smaller starting address (considered as an u= nsigned integer

       value) wins=

 &= nbsp; 7.  Smaller starting SID wins

&n= bsp;

I= f you were to seriously try to focus on “network availability” = we would need to incorporate additional information which might include:

<= o:p> 

=B7       = ;  Is a prefix reachable?

=B7       = ;  How much traffic depends on each prefix

=B7       = ;  What class of traffic depends on each prefix

&n= bsp;

[Bruno] I guess it depends on h= ow we define “network availability”. We can rephrase as PE/FEC = availability if you want.

And yes, network operator are s= erious about network availability. I’d assume that box vendor are ser= ious about box availability.

&n= bsp;

T= his can only increase the complexity of the implementation – and I ha= ve no doubt the debate about the best heuristics could go on without end.

[Bruno] I’m not asking fo= r maximizing the PE/FEC availability. I’m asking for not using the te= rm “maximizing”, since this is not what we are looking for (nor= doing).

<= o:p> 

I= return again to the priorities which the authors stated from the beginning= :

<= o:p> 

1)Detect the problem<= /p>

2)Report the problem<= /p>

3)Define consistent behavior<= /i>

4)Don’t overengineer the solution

Given that it is impossible to know which of th= e conflicting entries

is the correct one, we should apply a simple al= gorithm to resolve the conflict.

5= )Agree on the resolution behavior

 

<= o:p> 

F= or some of us, the resolution behavior is the least important. For you it s= eems it is the most important.

[Bruno] We all agree on points = 1 to 3 so there is no need to discuss them.

What is important is the end re= sult for the users of the network. And that’s not even in the authors= list of priority, even after two years of discussion and statements from m= ultiple network operators that this point it important.

 

--Bruno

<= o:p> 

T= hat is what  the debate is really about.

<= o:p> 

&= nbsp;  Les

<= o:p> 

--Bruno=

&n= bsp;

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, December 09, 2016 7:31 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

Bruno &= #8211;

&n= bsp;

Welcome= back to the discussion. J=

Inline.=

&n= bsp;

From: bruno.decraene@orange.com [ma= ilto:bruno.decraene@orange.com]
Sent: Friday, December 09, 2016 2:07 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

Hi Les,=

&n= bsp;

As a in= dividual contributor, please find below some clarification questions [Bruno= ]

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, December 05, 2016 1:04 AM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal

 

When the problem addressed b= y draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the au= thors defined the following priorities:

 

1)Detect the problem

2)Report the problem

This alerts the network oper= ator to the existence of a conflict so that

the configuration error can = be corrected.

3)Define consistent behavior=

This avoids mis-forwarding w= hile the conflict exists.

4)Don’t overengineer t= he solution

Given that it is impossible = to know which of the conflicting entries

is the correct one, we shoul= d apply a simple algorithm to resolve the conflict.

5)Agree on the resolution be= havior

 

The resolution behavior was = deliberately the last point because it was

considered the least importa= nt.

 

Input was received over the = past year which emphasized the importance of

trying to "maximize for= warding" in the presence of conflicts. Subsequent

revisions of the draft have = tried to address this concern. However the authors

have repeatedly stressed tha= t the solution being proposed

("ignore overlap only&q= uot;) was more complex than other offered alternatives and

would be more difficult to g= uarantee interoperability because subtle

differences in an implementa= tion could produce different results.

 

At IETF97 significant feedba= ck was received preferring a simpler solution to

the problem. The authors are= very sympathetic to this feedback and therefore

are proposing a solution bas= ed on what the draft defines as the "Ignore"

policy - where all entries w= hich are in conflict are ignored. We believe this

is far more desirable and al= igns with the priorities listed above.

 

[Bru= no] In the draft, the “Ignore” policy (=A73.3.1) ignores all co= nflicting entries.

In y= our below proposition, the policy seems to pick the most preferred entry. T= his looks like more similar to the “Quarantine” policy proposed= in the draft (=A73.3.2)

Am I= missing something?

 

[Les:] At the time “Ignore” was introduced (over a year ago) = the notion of “SRMS preference” did not exist – that was = only added in the most recent version of the draft.

We (the authors) feel that this is a useful construct because:=

 

1)It provides an explicit basis on which to choose between conflicting en= tries.

2)It is particularly useful when bringing up a new SRMS as it allows the = advertised values to be verified before they are used.

 

So, your comment is correct in that there is now a preference algorithm i= n use – whereas with the original definition of “Ignore” = there was no preference algorithm. But the sole criteria of the preference rule is the explicitly configured preference – non= e of the other criteria proposed for Quarantine are used – and in par= ticular we do not make partial use of a mapping entry as is the case with &= #8220;Ignore Overlap Only”.

 

I am happy to modify the nomenclature – but the point of this threa= d is not to replace a new draft revision – it is to get the sense of = the WG before we publish a new revision as to whether we should continue down the “Ignore Overlap only” path or move= to a simpler strategy – so let’s not be too picky about the na= ming.

 

We outline the proposed solu= tion below and would like to receive feedback from

the WG before publishing the= next revision of the draft.

 

   Les (on behalf = of the authors)

 

New Proposal

 <= /i>

In the latest revision of= the draft "SRMS Preference" was introduced. This

provides a way for a nume= rical preference to be explicitly associated with an

SRMS advertisement. Using= this an operator can indicate which advertisement is

to be preferred when a co= nflict is present. The authors think this is a useful

addition and we therefore= want to include this in the new solution.

 <= /i>

The new preference rule u= sed to resolve conflicts is defined as follows:

 <= /i>

A given mapping entry = is compared against all mapping entries in the database

with a preference grea= ter than or equal to its own. If there is a conflict,

the mapping entry with= lower preference is ignored. If two mapping entries are<= /i>

in conflict and have e= qual preference then both entries are ignored.

 <= /i>

Implementation of this po= licy is defined as follows:

 <= /i>

Step 1: Within a singl= e address-family/algorithm/topology sort entries

based on preference

[Bru= no] I’m not sure what you are refering to by “preference”= . Is this the IGP “SRMS Preference sub-TLV” or is this the pref= erence defined in the draft (=A73.3.4)?

 

[Les:] It is the former.

 

Assu= ming you meant the SRMS preference, why limiting to this field, rather than= including all fields defined in the draft preference algo?

Usin= g the latter would reduce the risk of ignoring all entries (i.e. having no = entry in output of this algo). Also a priori,  a sort would not be req= uired as a single pass could select the most preferred entry.

 

[Les:] The point of the alternative proposal is a simplification. The pre= sentation in Seoul (check out the slides) highlighted complexities in the i= mplementation of “ignore-overlap-only” – in particular subtleties in the order in which an implementation l= ooks at entries which could produce interoperability issues even though imp= lementations are using the same preference rule. The alternative reduces th= e chances of these interoperability issues occurring because the algorithm used is simpler and less subject to subtle= implementation differences.

 

If you want to argue that these are solvable problems I won’t disag= ree with you – it is a question of where we want to put our time and = effort. A number of folks are commenting that they prefer to focus on fixing the configuration and not invest  time in v= alidating that conflict resolution is implemented in an interoperable way. = As we (the authors) have stated from the beginning, we believe the emphasis= should be on detecting and reporting the conflicts – not spending cycles implementing the most robust mea= ns of trying to operate optimally while the misconfiguration exists. I know= you disagree on this point – but that is exactly what the WG is deba= ting – not whether it is possible to make “ignore overlap only” work.

 

   Les

 

Than= ks

-- B= runo

 

Step 2: Starting with = the lowest preference entries, resolve prefix conflicts

using the above prefer= ence rule. The output is an active policy per topology.

Step 3: Take the outpu= ts from Step 2 and again sort them by preference

Step 4: Starting with = the lowest preference entries, resolve SID conflicts

using the above prefer= ence rule

 

The output from Step 4= is then the current Active Policy.

 

Here are a few examples. Eac= h mapping entry is represented by the tuple:

(Preference, Prefix/mask Ind= ex range <#>)

 

Example 1:=

 

1. (150, 1.1.1.1/32 100 rang= e 100)

2. (149, 1.1.1.10/32 200 ran= ge 200)

3. (148, 1.1.1.101/32 500 ra= nge 10)

 

Entry 3 conflicts with entry= 2, it is ignored.

Entry 2 conflicts with entry= 1, it is ignored.

Active policy:

 

(150, 1.1.1.1/32 100 range 1= 00)

 

Example 2:=

 

1. (150, 1.1.1.1/32 100 rang= e 100)

2. (150, 1.1.1.10/32 200 ran= ge 200)

3. (150, 1.1.1.101/32 500 ra= nge 10)

4. (150, 2.2.2.1/32 1000 ran= ge 1)

 

Entry 1 conflicts with entry= 2, both are marked as ignore.

Entry 3 conflicts with entry= 2. It is marked as ignore.

Entry 4 has no conflicts wit= h any entries

 

Active policy:

(150, 2.2.2.1/32 1000 range = 1)

 

Example 3:=

 

1. (150, 1.1.1.1/32 100 rang= e 500)

2. (150, 1.1.1.10/32 200 ran= ge 200)

3. (150, 1.1.1.101/32 500 ra= nge 10)

4. (150, 2.2.2.1/32 1000 ran= ge 1)

 

Entry 1 conflicts with entri= es 2, 3, and  4. All entries are marked ignore.

 

Active policy:

Empty

 

Example 4:=

 

1. (150, 1.1.1.1/32 100 rang= e 10)

2. (149, 1.1.1.10/32 200 ran= ge 300)

3. (149, 1.1.1.101/32 500 ra= nge 10)

4. (148, 2.2.2.1/32 1000 ran= ge 1)

 

Entry 4 conflicts with entry= 2. It is marked ignore.

Entry 2 conflicts with entry= 3. Entries 2 and 3 are marked ignore.

 

Active policy:

(150, 1.1.1.1/32 100 range 10)

 

 

 

 

_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
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.
 
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 author=
isation.
If you have received this email in error, please notify the s=
ender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.
T=
hank you.
_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
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.
 
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 author=
isation.
If you have received this email in error, please notify the s=
ender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages t=
hat have been modified, 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_53C29892C857584299CBF5D05346208A1ECE7974OPEXCLILM21corp_-- From nobody Thu Jan 5 08:47:49 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 43E7C129563 for ; Thu, 5 Jan 2017 08:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, 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 7xVooQJtoZie for ; Thu, 5 Jan 2017 08:47:43 -0800 (PST) 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 4A46F129496 for ; Thu, 5 Jan 2017 08:47:43 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id C378560701; Thu, 5 Jan 2017 17:47:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 9B469180065; Thu, 5 Jan 2017 17:47:41 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0319.002; Thu, 5 Jan 2017 17:47:41 +0100 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: SID Conflict Resolution: A Simpler Proposal Thread-Index: AdJOibcaOvA8JiDrT2eiOTpEk40qzwDdlkBwAA8oUZACVgRskAAWou1gAA1VBGAC0MCgAA== Date: Thu, 5 Jan 2017 16:47:41 +0000 Message-ID: <13073_1483634861_586E78AD_13073_628_1_53C29892C857584299CBF5D05346208A1ECE799D@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <84fe7b43d5054712abf09b274bc3c471@XCH-ALN-001.cisco.com> <13659_1481278031_584A824F_13659_1413_1_53C29892C857584299CBF5D05346208A1ECBEDCF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <2599_1482331179_585A942B_2599_15892_1_53C29892C857584299CBF5D05346208A1ECCA7D8@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1f3288d0ea20445389ca2dab011df9de@XCH-ALN-001.cisco.com> <10ea072784584a99b56d4d7ebac2b86c@XCH-ALN-001.cisco.com> In-Reply-To: <10ea072784584a99b56d4d7ebac2b86c@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.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ECE799DOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jan 2017 16:47:48 -0000 --_000_53C29892C857584299CBF5D05346208A1ECE799DOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Les, I'm not sure that the problem is exactly the same for routers and for contr= ollers: - Routers do transit, hence we MUST achieve consistency to avoid mis-routin= g (e.g SID 1 used for 1.0.0.1 by some nodes and for 1.0.0.2 by some other n= odes) or black-holing (e.g. SID 1 used for 1.0.0.1 by some (source) nodes b= ut dropped by some other (transit) nodes). - In SR, the "Controler" would typically control the ingress/"source routin= g node" behavior. It can choose, independently, to not use a SID/prefix in = case of conflict. (a la "ignore all") So the problem looks different and it seems that the solution selected may = also be different. > I am not optimistic that all controllers will implement conflict resoluti= on. Well, I think that open source can help: it's enough if a single "one" imp= lements the right conflict resolution behavior. And we have running code sh= owing that a per FEC behavior can be implemented by "one". --Bruno From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Thursday, December 22, 2016 8:42 AM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal And one more thought for everyone to mull over while enjoying the holidays.= .. Consistency is a requirement of any solution i.e. all routers in the networ= k MUST use the same algorithm operating on the same database. However, this requirement goes beyond routers - it is also required of any = entity - specifically controllers - which might specify an engineered path = consisting of prefix SIDs. I think no one questions that all routers will implement the standardized s= olution - but will all controllers? Consider the consequences if a controller does not implement the solution. We have the following conflict: (192, 1.1.1.1/32 100 range 1) (192, 2.2.2.2/32 100 range 1) If we use a policy which chooses a winning entry in such a case (such as "I= gnore Overlap Only") the winner will be (192, 1.1.1.1/32 100 range 1) (base= d on current preference rules defined in the draft). Labels associated with SID 100 will be installed in router forwarding plans= and direct traffic towards 1.1.1.1. If we use a policy which does not use either of the conflicting entries rou= ters will NOT install labels associated with SID 100 in the forwarding plan= e and traffic arriving with such a label will be dropped. If a controller which does NOT do conflict resolution builds an engineered = path which traverses 2.2.2.2, it will send a label stack including SID 100. Using "Ignore Overlap Only", routers will forward a packet with SID 100 tow= ards 1.1.1.1 rather than 2.2.2.2. Using "Ignore", packets using SID 100 will be dropped. I am not optimistic that all controllers will implement conflict resolution= . If I am right, the consequences of the combination of the Conflict Resolu= tion policy chosen and a Controller which does not implement conflict resol= ution should be considered. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Wednesday, December 21, 2016 5:50 PM To: bruno.decraene@orange.com Cc: spring@ietf.org Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal Bruno - From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, December 21, 2016 6:40 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Les, Still as an individual contributor, SID conflict resolution is about a trad= e-off between implementation complexity and network availability. Hence eva= luating the consequences on network availability is at least as important a= s evaluating the implementation complexity; especially as the former is eas= ier to quantify while the latter may be implementation specific. So on this= FEC/network availability standpoint, please find below three comments. 1) The slides presented might IMHO slightly mislead a reader: - the discussion on network availability compares "Quarantine" vs "Ignore O= verlap" - the conclusion discuss "Ignore Overlap" vs "Ignore" So they are comparing different things, while a quick reader may assume tha= t apples were compared to apples. Note that I'm not saying (and not thinking) that this is misleading on purp= ose. I'm expressing the way I read it. [Les:] Please remember the history here. Prior to Seoul the input we had wa= s: "Ignore" is least desirable - evaluate between "Quarantine" and "Ignore Ove= rlap". The discussion over the previous few months therefore was comparing the lat= ter two. Slides for both Berlin and Seoul were therefore prepared with that= in mind. Significant feedback at Seoul and since has made "Ignore" a candidate again= - so the email thread has now focused on "Ignore" vs "Ignore Overlap Only". If I had received this feedback before Seoul I would have prepared differen= t slides. My apologies for not being clairvoyant. :) 2) Regarding the new proposal, post Seoul, it is vocal on the complexity si= de, but not on the network availability side which is not evaluated. This d= oes not helps the WG understanding of the trade-off involved and the making= of an informed decision. I'm even wondering if the network availability has been considered since by= default, this proposal seems to kill, by design, the SRMS and SR-LDP inter= -working. SRMS has been designed in order to allow for the inter-working with LDP, in= a brown-field scenario where SR is introduced in a LDP MPLS network. e.g. a typical set of advertisements would be 1. PrefixSID: (192, 1.1.1.1/32 100 range 1) 2. MS: (128, 1.1.1.1/32 100 range 255) With this simple example, not even having a configuration error but using a= nominal configuration, the MS advertisement would be ignored with the igno= re policy, hence the LDP interwork would not work, and all LDP/non-SR nodes= would loose SID hence loose SR connectivity. Eventually, you may change the algorithm, to look beyond the most preferred= entry, and check whether the SIDs are really different or not. And if not,= change the algo to pick the largest range rather than the highest preferen= ce. But this is adding complexity to cover a specific case, while keeping t= he solution weak in term of network availability, in the general case. e.g.= if we do have a different SID, many prefix (99%) would lose their SID. [Les:] Your interpretation is incorrect. There is no conflict in the exampl= e you provide - therefore no entries will be ignored (this is true no matte= r what conflict resolution strategy is chosen). The definition of conflicts can be found in Section 3.2 of the draft. Nothi= ng in this discussion proposes changes to that- and the definition of a con= flict has never been under debate. What we have discussed over the last 6 months or more has been what to do w= hen conflicts exist- this is Section 3.3 of the draft. 3) Finally, when discussing "Ignore Overlap", a typical quote from the auth= ors is "maximize forwarding" or "operate optimally", as if we were trying t= o optimize for the last bit. But note that "Ignore Overlap" is _not_ maximi= zing forwarding. Maximizing forwarding would be much more complex, and nob= ody on the list has even tried for this, including draft-ietf-spring-confli= ct-resolution. e.g. with following advertisements with a misconfiguration 1. PrefixSID: (192, 1.1.1.1/32 101 range 1) 2. MS: (128, 1.1.1.1/32 100 range 255) During prefix conflict, for 1.1.1.1/32 Ignore Overlap selects the SID from = prefixSID entry, which will latter have a SID conflict with the MS entry (S= ID 101, prefixes 1.1.1.1 vs 1.1.1.2). As a result, 1.1.1.2 won't get a SID. In this specific case, a solution "maximizing the forwarding" would have ig= nored the PrefixSID. But in the general case, "maximizing the forwarding" m= ay require evaluating all options, and then pick the best one based on all = results. So please let's keep evaluating the impact on the network availability. Ber= lin presentation was a good example on this. [Les:] Well, the Berlin slides (see Slide 25) use the term "Maximize SR For= warding". https://www.ietf.org/proceedings/96/slides/slides-96-spring-4.pdf One of the problems with making a choice when conflicts exist is that there= is no way of knowing what prefixes are the most important in a particular = network deployment. "Ignore overlap only" aimed to maximize the number of = prefixes which had SIDs in the hope that we would have a greater chance of = including the more important prefixes - but since all of our tie-breakers a= re simply arbitrary choices there is no guarantee. From Section 3.3.4 of th= e draft: 2 Smaller range wins 3. IPv6 entry wins over IPv4 entry 4. Longer prefix length wins 5. Smaller algorithm wins 6. Smaller starting address (considered as an unsigned integer value) wins 7. Smaller starting SID wins If you were to seriously try to focus on "network availability" we would ne= ed to incorporate additional information which might include: =B7 Is a prefix reachable? =B7 How much traffic depends on each prefix =B7 What class of traffic depends on each prefix This can only increase the complexity of the implementation - and I have no= doubt the debate about the best heuristics could go on without end. I return again to the priorities which the authors stated from the beginnin= g: 1)Detect the problem 2)Report the problem 3)Define consistent behavior 4)Don't overengineer the solution Given that it is impossible to know which of the conflicting entries is the correct one, we should apply a simple algorithm to resolve the confl= ict. 5)Agree on the resolution behavior For some of us, the resolution behavior is the least important. For you it = seems it is the most important. That is what the debate is really about. Les --Bruno From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, December 09, 2016 7:31 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Bruno - Welcome back to the discussion. :) Inline. From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Friday, December 09, 2016 2:07 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Hi Les, As a individual contributor, please find below some clarification questions= [Bruno] From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Monday, December 05, 2016 1:04 AM To: spring@ietf.org Subject: [spring] SID Conflict Resolution: A Simpler Proposal When the problem addressed by draft-ietf-spring-conflict-resolution was fir= st presented at IETF 94, the authors defined the following priorities: 1)Detect the problem 2)Report the problem This alerts the network operator to the existence of a conflict so that the configuration error can be corrected. 3)Define consistent behavior This avoids mis-forwarding while the conflict exists. 4)Don't overengineer the solution Given that it is impossible to know which of the conflicting entries is the correct one, we should apply a simple algorithm to resolve the confl= ict. 5)Agree on the resolution behavior The resolution behavior was deliberately the last point because it was considered the least important. Input was received over the past year which emphasized the importance of trying to "maximize forwarding" in the presence of conflicts. Subsequent revisions of the draft have tried to address this concern. However the auth= ors have repeatedly stressed that the solution being proposed ("ignore overlap only") was more complex than other offered alternatives and would be more difficult to guarantee interoperability because subtle differences in an implementation could produce different results. At IETF97 significant feedback was received preferring a simpler solution to the problem. The authors are very sympathetic to this feedback and therefore are proposing a solution based on what the draft defines as the "Ignore" policy - where all entries which are in conflict are ignored. We believe th= is is far more desirable and aligns with the priorities listed above. [Bruno] In the draft, the "Ignore" policy (=A73.3.1) ignores all conflictin= g entries. In your below proposition, the policy seems to pick the most preferred entr= y. This looks like more similar to the "Quarantine" policy proposed in the = draft (=A73.3.2) Am I missing something? [Les:] At the time "Ignore" was introduced (over a year ago) the notion of = "SRMS preference" did not exist - that was only added in the most recent ve= rsion of the draft. We (the authors) feel that this is a useful construct because: 1)It provides an explicit basis on which to choose between conflicting entr= ies. 2)It is particularly useful when bringing up a new SRMS as it allows the ad= vertised values to be verified before they are used. So, your comment is correct in that there is now a preference algorithm in = use - whereas with the original definition of "Ignore" there was no prefere= nce algorithm. But the sole criteria of the preference rule is the explicit= ly configured preference - none of the other criteria proposed for Quaranti= ne are used - and in particular we do not make partial use of a mapping ent= ry as is the case with "Ignore Overlap Only". I am happy to modify the nomenclature - but the point of this thread is not= to replace a new draft revision - it is to get the sense of the WG before = we publish a new revision as to whether we should continue down the "Ignore= Overlap only" path or move to a simpler strategy - so let's not be too pic= ky about the naming. We outline the proposed solution below and would like to receive feedback f= rom the WG before publishing the next revision of the draft. Les (on behalf of the authors) New Proposal In the latest revision of the draft "SRMS Preference" was introduced. This provides a way for a numerical preference to be explicitly associated with = an SRMS advertisement. Using this an operator can indicate which advertisement= is to be preferred when a conflict is present. The authors think this is a use= ful addition and we therefore want to include this in the new solution. The new preference rule used to resolve conflicts is defined as follows: A given mapping entry is compared against all mapping entries in the databa= se with a preference greater than or equal to its own. If there is a conflict, the mapping entry with lower preference is ignored. If two mapping entries = are in conflict and have equal preference then both entries are ignored. Implementation of this policy is defined as follows: Step 1: Within a single address-family/algorithm/topology sort entries based on preference [Bruno] I'm not sure what you are refering to by "preference". Is this the = IGP "SRMS Preference sub-TLV" or is this the preference defined in the draf= t (=A73.3.4)? [Les:] It is the former. Assuming you meant the SRMS preference, why limiting to this field, rather = than including all fields defined in the draft preference algo? Using the latter would reduce the risk of ignoring all entries (i.e. having= no entry in output of this algo). Also a priori, a sort would not be requ= ired as a single pass could select the most preferred entry. [Les:] The point of the alternative proposal is a simplification. The prese= ntation in Seoul (check out the slides) highlighted complexities in the imp= lementation of "ignore-overlap-only" - in particular subtleties in the orde= r in which an implementation looks at entries which could produce interoper= ability issues even though implementations are using the same preference ru= le. The alternative reduces the chances of these interoperability issues oc= curring because the algorithm used is simpler and less subject to subtle im= plementation differences. If you want to argue that these are solvable problems I won't disagree with= you - it is a question of where we want to put our time and effort. A numb= er of folks are commenting that they prefer to focus on fixing the configur= ation and not invest time in validating that conflict resolution is implem= ented in an interoperable way. As we (the authors) have stated from the beg= inning, we believe the emphasis should be on detecting and reporting the co= nflicts - not spending cycles implementing the most robust means of trying = to operate optimally while the misconfiguration exists. I know you disagree= on this point - but that is exactly what the WG is debating - not whether = it is possible to make "ignore overlap only" work. Les Thanks -- Bruno Step 2: Starting with the lowest preference entries, resolve prefix conflic= ts using the above preference rule. The output is an active policy per topolog= y. Step 3: Take the outputs from Step 2 and again sort them by preference Step 4: Starting with the lowest preference entries, resolve SID conflicts using the above preference rule The output from Step 4 is then the current Active Policy. Here are a few examples. Each mapping entry is represented by the tuple: (Preference, Prefix/mask Index range <#>) Example 1: 1. (150, 1.1.1.1/32 100 range 100) 2. (149, 1.1.1.10/32 200 range 200) 3. (148, 1.1.1.101/32 500 range 10) Entry 3 conflicts with entry 2, it is ignored. Entry 2 conflicts with entry 1, it is ignored. Active policy: (150, 1.1.1.1/32 100 range 100) Example 2: 1. (150, 1.1.1.1/32 100 range 100) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entry 2, both are marked as ignore. Entry 3 conflicts with entry 2. It is marked as ignore. Entry 4 has no conflicts with any entries Active policy: (150, 2.2.2.1/32 1000 range 1) Example 3: 1. (150, 1.1.1.1/32 100 range 500) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entries 2, 3, and 4. All entries are marked ignore. Active policy: Empty Example 4: 1. (150, 1.1.1.1/32 100 range 10) 2. (149, 1.1.1.10/32 200 range 300) 3. (149, 1.1.1.101/32 500 range 10) 4. (148, 2.2.2.1/32 1000 range 1) Entry 4 conflicts with entry 2. It is marked ignore. Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore. Active policy: (150, 1.1.1.1/32 100 range 10) ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ECE799DOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Les,

&n= bsp;

I’= ;m not sure that the problem is exactly the same for routers and for contro= llers:

- Route= rs do transit, hence we MUST achieve consistency to avoid mis-routing (e.g = SID 1 used for 1.0.0.1 by some nodes and for 1.0.0.2 by some other nodes) o= r black-holing (e.g. SID 1 used for 1.0.0.1 by some (source) nodes but dropped by some other (transit) nodes).

- In SR= , the “Controler” would typically control the ingress/”so= urce routing node” behavior. It can choose, independently, to not use= a SID/prefix in case of conflict. (a la “ignore all”)

&n= bsp;

So the = problem looks different and it seems that the solution selected may also be= different.

&n= bsp;

> I = am not optimistic that all controllers will implement conflict resolution.<= o:p>

&n= bsp;

Well,&n= bsp; I think that open source can help: it’s enough if a single ̶= 0;one” implements the right conflict resolution behavior. And we have= running code showing that a per FEC behavior can be implemented by “one”.

&n= bsp;

--Bruno=

&n= bsp;

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.c= om]
Sent: Thursday, December 22, 2016 8:42 AM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

And one= more thought for everyone to mull over while enjoying the holidays…<= o:p>

&n= bsp;

Consist= ency is a requirement of any solution i.e. all routers in the network MUST = use the same algorithm operating on the same database.

However= , this requirement goes beyond routers – it is also required of any e= ntity – specifically controllers – which might specify an engin= eered path consisting of prefix SIDs.

&n= bsp;

I think= no one questions that all routers will implement the standardized solution= – but will all controllers?

&n= bsp;

Conside= r the consequences if a controller does not implement the solution.

&n= bsp;

We have= the following conflict:

&n= bsp;

(192, 1= .1.1.1/32 100 range 1)

(192, 2= .2.2.2/32 100 range 1)

&n= bsp;

If we u= se a policy which chooses a winning entry in such a case (such as “Ig= nore Overlap Only”) the winner will be (192, 1.1.1.1/32 100 range 1) = (based on current preference rules defined in the draft).

Labels = associated with SID 100 will be installed in router forwarding plans and di= rect traffic towards 1.1.1.1.

&n= bsp;

If we u= se a policy which does not use either of the conflicting entries routers wi= ll NOT install labels associated with SID 100 in the forwarding plane and t= raffic arriving with such a label will be dropped.

&n= bsp;

If a co= ntroller which does NOT do conflict resolution builds an engineered path wh= ich traverses 2.2.2.2, it will send a label stack including SID 100.

&n= bsp;

Using &= #8220;Ignore Overlap Only”, routers will forward a packet with SID 10= 0 towards 1.1.1.1 rather than 2.2.2.2.

&n= bsp;

Using &= #8220;Ignore”, packets using SID 100 will be dropped.

&n= bsp;

I am no= t optimistic that all controllers will implement conflict resolution. If I = am right, the consequences of the combination of the Conflict Resolution po= licy chosen and a Controller which does not implement conflict resolution should be considered.<= /p>

&n= bsp;

  = Les

&n= bsp;

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, December 21, 2016 5:50 PM
To: bruno.decraene@orange.com
Cc: spring@ietf.org
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

 

Bruno -=

&n= bsp;

From: bruno.decraene@orange.com [ma= ilto:bruno.decraene@orange.com]
Sent: Wednesday, December 21, 2016 6:40 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

Les,

&n= bsp;

Still a= s an individual contributor, SID conflict resolution is about a trade-off b= etween implementation complexity and network availability. Hence evaluating= the consequences on network availability is at least as important as evaluating the implementation complexity; espe= cially as the former is easier to quantify while the latter may be implemen= tation specific. So on this FEC/network availability standpoint, please fin= d below three comments.

&n= bsp;

1) The = slides presented might IMHO slightly mislead a reader:

- the d= iscussion on network availability compares "Quarantine" vs "= Ignore Overlap"

- the c= onclusion discuss "Ignore Overlap" vs "Ignore"

&n= bsp;

So they= are comparing different things, while a quick reader may assume that apple= s were compared to apples.

Note th= at I'm not saying (and not thinking) that this is misleading on purpose. I'= m expressing the way I read it.

&n= bsp;

[= Les:] Please remember the history here. Prior to Seoul the input we had was= :

&= #8220;Ignore” is least desirable – evaluate between “Quar= antine” and “Ignore Overlap”.

T= he discussion over the previous few months therefore was comparing the latt= er two. Slides for both Berlin and Seoul were therefore prepared with that = in mind.

<= o:p> 

S= ignificant feedback at Seoul and since has made “Ignore” a cand= idate again – so the email thread has now focused on “Ignore= 221; vs “Ignore Overlap Only”.

I= f I had received this feedback before Seoul I would have prepared different= slides.

<= o:p> 

M= y apologies for not being clairvoyant. J<= o:p>

&n= bsp;

2) Rega= rding the new proposal, post Seoul, it is vocal on the complexity side, but= not on the network availability side which is not evaluated. This does not= helps the WG understanding of the trade-off involved and the making of an informed decision.

I'm eve= n wondering if the network availability has been considered since by defaul= t, this proposal seems to kill, by design, the SRMS and SR-LDP inter-workin= g.

SRMS ha= s been designed in order to allow for the inter-working with LDP, in a brow= n-field scenario where SR is introduced in a LDP MPLS network.

e.g. a = typical set of advertisements would be

1. Pref= ixSID: (192, 1.1.1.1/32 100 range 1)

2. MS: =        (128, 1.1.1.1/32 100 range 255)

&n= bsp;

With th= is simple example, not even having a configuration error but using a nomina= l configuration, the MS advertisement would be ignored with the ignore poli= cy, hence the LDP interwork would not work, and all LDP/non-SR nodes would loose SID hence loose SR connectivity= .

Eventua= lly, you may change the algorithm, to look beyond the most preferred entry,= and check whether the SIDs are really different or not. And if not, change= the algo to pick the largest range rather than the highest preference. But this is adding complexity to cover a spec= ific case, while keeping the solution weak in term of network availability,= in the general case. e.g. if we do have a different SID, many  prefix= (99%) would lose their SID.

&n= bsp;

[= Les:] Your interpretation is incorrect. There is no conflict in the example= you provide – therefore no entries will be ignored (this is true no = matter what conflict resolution strategy is chosen).

T= he definition of conflicts can be found in Section 3.2 of the draft. Nothin= g in this discussion proposes changes to that- and the definition of a conf= lict has never been under debate.

<= o:p> 

W= hat we have discussed over the last 6 months or more has been what to do wh= en conflicts exist- this is Section 3.3 of the draft.=

&n= bsp;

&n= bsp;

3) Fina= lly, when discussing "Ignore Overlap", a typical quote from the a= uthors is "maximize forwarding" or "operate optimally",= as if we were trying to optimize for the last bit. But note that "Ign= ore Overlap" is _not_ maximizing forwarding.  Maximizing forwarding = would be much more complex, and nobody on the list has even tried for this,= including draft-ietf-spring-conflict-resolution.

e.g. wi= th following advertisements with a misconfiguration

1. Pref= ixSID: (192, 1.1.1.1/32 101 range 1)

2. MS:&= nbsp;       (128, 1.1.1.1/32 100 range 255)

&n= bsp;

During = prefix conflict, for 1.1.1.1/32 Ignore Overlap selects the SID from prefixS= ID entry, which will latter have a SID conflict with the MS entry (SID 101,= prefixes 1.1.1.1 vs 1.1.1.2). As a result, 1.1.1.2 won't get a SID.

In this= specific case, a solution "maximizing the forwarding" would have= ignored the PrefixSID. But in the general case, "maximizing the forwa= rding" may require evaluating all options, and then pick the best one based on all results.

&n= bsp;

&n= bsp;

So plea= se let’s keep evaluating the impact on the network availability. Berl= in presentation was a good example on this.

[= Les:] Well, the Berlin slides (see Slide 25) use the term “Maximize S= R Forwarding”.

https://www.ietf.org/p= roceedings/96/slides/slides-96-spring-4.pdf

<= o:p> 

<= o:p> 

O= ne of the problems with making a choice when conflicts exist is that there = is no way of knowing what prefixes are the most important in a particular n= etwork deployment.  “Ignore overlap only” aimed to maximize the number of prefixes which had SIDs in the hope that w= e would have a greater chance of including the more important prefixes R= 11; but since all of our tie-breakers are simply arbitrary choices there is= no guarantee. From Section 3.3.4 of the draft:

<= o:p> 

2 Smaller range wins

3.  IPv6 entry wins over IPv4 entry

4.  Longer prefix length wins<= /p>

5.  Smaller algorithm wins

6.  Smaller starting address (considered as an u= nsigned integer

       value) wins=

 &= nbsp; 7.  Smaller starting SID wins

&n= bsp;

I= f you were to seriously try to focus on “network availability” = we would need to incorporate additional information which might include:

<= o:p> 

=B7       = ;  Is a prefix reachable?

=B7       = ;  How much traffic depends on each prefix

=B7       = ;  What class of traffic depends on each prefix

&n= bsp;

T= his can only increase the complexity of the implementation – and I ha= ve no doubt the debate about the best heuristics could go on without end.

<= o:p> 

I= return again to the priorities which the authors stated from the beginning= :

<= o:p> 

1)Detect the problem<= /p>

2)Report the problem<= /p>

3)Define consistent behavior<= /i>

4)Don’t overengineer the solution

Given that it is impossible to know which of th= e conflicting entries

is the correct one, we should apply a simple al= gorithm to resolve the conflict.

5= )Agree on the resolution behavior

 

<= o:p> 

F= or some of us, the resolution behavior is the least important. For you it s= eems it is the most important.

T= hat is what  the debate is really about.

<= o:p> 

&= nbsp;  Les

<= o:p> 

--Bruno=

&n= bsp;

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, December 09, 2016 7:31 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

Bruno &= #8211;

&n= bsp;

Welcome= back to the discussion. J=

Inline.=

&n= bsp;

From: bruno.decraene@orange.com [ma= ilto:bruno.decraene@orange.com]
Sent: Friday, December 09, 2016 2:07 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

Hi Les,=

&n= bsp;

As a in= dividual contributor, please find below some clarification questions [Bruno= ]

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, December 05, 2016 1:04 AM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal

 

When the problem addressed b= y draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the au= thors defined the following priorities:

 

1)Detect the problem

2)Report the problem

This alerts the network oper= ator to the existence of a conflict so that

the configuration error can = be corrected.

3)Define consistent behavior=

This avoids mis-forwarding w= hile the conflict exists.

4)Don’t overengineer t= he solution

Given that it is impossible = to know which of the conflicting entries

is the correct one, we shoul= d apply a simple algorithm to resolve the conflict.

5)Agree on the resolution be= havior

 

The resolution behavior was = deliberately the last point because it was

considered the least importa= nt.

 

Input was received over the = past year which emphasized the importance of

trying to "maximize for= warding" in the presence of conflicts. Subsequent

revisions of the draft have = tried to address this concern. However the authors

have repeatedly stressed tha= t the solution being proposed

("ignore overlap only&q= uot;) was more complex than other offered alternatives and

would be more difficult to g= uarantee interoperability because subtle

differences in an implementa= tion could produce different results.

 

At IETF97 significant feedba= ck was received preferring a simpler solution to

the problem. The authors are= very sympathetic to this feedback and therefore

are proposing a solution bas= ed on what the draft defines as the "Ignore"

policy - where all entries w= hich are in conflict are ignored. We believe this

is far more desirable and al= igns with the priorities listed above.

 

[Bru= no] In the draft, the “Ignore” policy (=A73.3.1) ignores all co= nflicting entries.

In y= our below proposition, the policy seems to pick the most preferred entry. T= his looks like more similar to the “Quarantine” policy proposed= in the draft (=A73.3.2)

Am I= missing something?

 

[Les:] At the time “Ignore” was introduced (over a year ago) = the notion of “SRMS preference” did not exist – that was = only added in the most recent version of the draft.

We (the authors) feel that this is a useful construct because:=

 

1)It provides an explicit basis on which to choose between conflicting en= tries.

2)It is particularly useful when bringing up a new SRMS as it allows the = advertised values to be verified before they are used.

 

So, your comment is correct in that there is now a preference algorithm i= n use – whereas with the original definition of “Ignore” = there was no preference algorithm. But the sole criteria of the preference rule is the explicitly configured preference – non= e of the other criteria proposed for Quarantine are used – and in par= ticular we do not make partial use of a mapping entry as is the case with &= #8220;Ignore Overlap Only”.

 

I am happy to modify the nomenclature – but the point of this threa= d is not to replace a new draft revision – it is to get the sense of = the WG before we publish a new revision as to whether we should continue down the “Ignore Overlap only” path or move= to a simpler strategy – so let’s not be too picky about the na= ming.

 

We outline the proposed solu= tion below and would like to receive feedback from

the WG before publishing the= next revision of the draft.

 

   Les (on behalf = of the authors)

 

New Proposal

 <= /i>

In the latest revision of= the draft "SRMS Preference" was introduced. This

provides a way for a nume= rical preference to be explicitly associated with an

SRMS advertisement. Using= this an operator can indicate which advertisement is

to be preferred when a co= nflict is present. The authors think this is a useful

addition and we therefore= want to include this in the new solution.

 <= /i>

The new preference rule u= sed to resolve conflicts is defined as follows:

 <= /i>

A given mapping entry = is compared against all mapping entries in the database

with a preference grea= ter than or equal to its own. If there is a conflict,

the mapping entry with= lower preference is ignored. If two mapping entries are<= /i>

in conflict and have e= qual preference then both entries are ignored.

 <= /i>

Implementation of this po= licy is defined as follows:

 <= /i>

Step 1: Within a singl= e address-family/algorithm/topology sort entries

based on preference

[Bru= no] I’m not sure what you are refering to by “preference”= . Is this the IGP “SRMS Preference sub-TLV” or is this the pref= erence defined in the draft (=A73.3.4)?

 

[Les:] It is the former.

 

Assu= ming you meant the SRMS preference, why limiting to this field, rather than= including all fields defined in the draft preference algo?

Usin= g the latter would reduce the risk of ignoring all entries (i.e. having no = entry in output of this algo). Also a priori,  a sort would not be req= uired as a single pass could select the most preferred entry.

 

[Les:] The point of the alternative proposal is a simplification. The pre= sentation in Seoul (check out the slides) highlighted complexities in the i= mplementation of “ignore-overlap-only” – in particular subtleties in the order in which an implementation l= ooks at entries which could produce interoperability issues even though imp= lementations are using the same preference rule. The alternative reduces th= e chances of these interoperability issues occurring because the algorithm used is simpler and less subject to subtle= implementation differences.

 

If you want to argue that these are solvable problems I won’t disag= ree with you – it is a question of where we want to put our time and = effort. A number of folks are commenting that they prefer to focus on fixing the configuration and not invest  time in v= alidating that conflict resolution is implemented in an interoperable way. = As we (the authors) have stated from the beginning, we believe the emphasis= should be on detecting and reporting the conflicts – not spending cycles implementing the most robust mea= ns of trying to operate optimally while the misconfiguration exists. I know= you disagree on this point – but that is exactly what the WG is deba= ting – not whether it is possible to make “ignore overlap only” work.

 

   Les

 

Than= ks

-- B= runo

 

Step 2: Starting with = the lowest preference entries, resolve prefix conflicts

using the above prefer= ence rule. The output is an active policy per topology.

Step 3: Take the outpu= ts from Step 2 and again sort them by preference

Step 4: Starting with = the lowest preference entries, resolve SID conflicts

using the above prefer= ence rule

 

The output from Step 4= is then the current Active Policy.

 

Here are a few examples. Eac= h mapping entry is represented by the tuple:

(Preference, Prefix/mask Ind= ex range <#>)

 

Example 1:=

 

1. (150, 1.1.1.1/32 100 rang= e 100)

2. (149, 1.1.1.10/32 200 ran= ge 200)

3. (148, 1.1.1.101/32 500 ra= nge 10)

 

Entry 3 conflicts with entry= 2, it is ignored.

Entry 2 conflicts with entry= 1, it is ignored.

Active policy:

 

(150, 1.1.1.1/32 100 range 1= 00)

 

Example 2:=

 

1. (150, 1.1.1.1/32 100 rang= e 100)

2. (150, 1.1.1.10/32 200 ran= ge 200)

3. (150, 1.1.1.101/32 500 ra= nge 10)

4. (150, 2.2.2.1/32 1000 ran= ge 1)

 

Entry 1 conflicts with entry= 2, both are marked as ignore.

Entry 3 conflicts with entry= 2. It is marked as ignore.

Entry 4 has no conflicts wit= h any entries

 

Active policy:

(150, 2.2.2.1/32 1000 range = 1)

 

Example 3:=

 

1. (150, 1.1.1.1/32 100 rang= e 500)

2. (150, 1.1.1.10/32 200 ran= ge 200)

3. (150, 1.1.1.101/32 500 ra= nge 10)

4. (150, 2.2.2.1/32 1000 ran= ge 1)

 

Entry 1 conflicts with entri= es 2, 3, and  4. All entries are marked ignore.

 

Active policy:

Empty

 

Example 4:=

 

1. (150, 1.1.1.1/32 100 rang= e 10)

2. (149, 1.1.1.10/32 200 ran= ge 300)

3. (149, 1.1.1.101/32 500 ra= nge 10)

4. (148, 2.2.2.1/32 1000 ran= ge 1)

 

Entry 4 conflicts with entry= 2. It is marked ignore.

Entry 2 conflicts with entry= 3. Entries 2 and 3 are marked ignore.

 

Active policy:

(150, 1.1.1.1/32 100 range 10)

 

 

 

 

_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
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.
 
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 author=
isation.
If you have received this email in error, please notify the s=
ender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.
T=
hank you.
_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
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.
 
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 author=
isation.
If you have received this email in error, please notify the s=
ender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages t=
hat have been modified, 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_53C29892C857584299CBF5D05346208A1ECE799DOPEXCLILM21corp_-- From nobody Thu Jan 5 08:50: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 F25B9129551 for ; Thu, 5 Jan 2017 08:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, 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 AYr6sfGNu1PD for ; Thu, 5 Jan 2017 08:50:11 -0800 (PST) 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 5A7F0129496 for ; Thu, 5 Jan 2017 08:50:11 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id B8D0CC0640; Thu, 5 Jan 2017 17:50:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 9646418004D; Thu, 5 Jan 2017 17:50:09 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Thu, 5 Jan 2017 17:50:09 +0100 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: SID Conflict Resolution: A Simpler Proposal Thread-Index: AdJOibcaOvA8JiDrT2eiOTpEk40qzwY5Ab7w Date: Thu, 5 Jan 2017 16:50:08 +0000 Message-ID: <9782_1483635009_586E7941_9782_1050_1_53C29892C857584299CBF5D05346208A1ECE79C3@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <84fe7b43d5054712abf09b274bc3c471@XCH-ALN-001.cisco.com> In-Reply-To: <84fe7b43d5054712abf09b274bc3c471@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.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ECE79C3OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jan 2017 16:50:14 -0000 --_000_53C29892C857584299CBF5D05346208A1ECE79C3OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An even simpler proposal for the prefix conflict: - if a SID is attached to the prefix (Prefix-SID Sub-TLV) use it. - IOW, prefix-SID have precedence over Mapping Server advertisements. (note= that this was the original text, a few years back in the IGP drafts) - This looks pretty simple as this is about disregarding (i= n fact not even looking at) MS entries. - otherwise looks for MS entries - there should be few since they are compressed using the "= range" field, so there should not be "scalability issues" - if this is still too complex to look for MS entries and p= ick one, I suppose that the Quarantine algo could be used on the MS entries= (at least SR capable nodes would not suffer from the conflict, and their p= roportion should increase over time). This would clearly simplify the draft, which is what you are calling for: n= o need to introduce the following complexities: "Generalized Mapping entry"= , "derived mapping entries" and their associated complexity. As a consequen= ce, this would also simplify the discussion in the WG. Additional advantages are: - implementations would not be mandated to support the Mapping Server at al= l (neither server nor client side). This is interesting for vendors not hav= ing deployment case mandating LDP interworking. (e.g. greenfield deployment= , possibly DC environment, mono-vendor networks) - advertisement from SR nodes are always used and do not conflict. As time = goes, we should expect that the proportion of SR compatible nodes increase,= which in the long run favor the simple rule (don't even consider SRMS) and= the absence of conflict (while with SRMS, we have, by design, multiple adv= ertisements covering the same prefix: 2 SRMS advertisements for redundancy,= plus Prefix SID for SR nodes. Hence chance to have conflict in case not al= l configurations are equals) - in the long run, we could deprecate MS entries and SR-LDP interworking, w= ith no impact on the selection rules/selected entries. Regards, --Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Monday, December 05, 2016 1:04 AM To: spring@ietf.org Subject: [spring] SID Conflict Resolution: A Simpler Proposal When the problem addressed by draft-ietf-spring-conflict-resolution was fir= st presented at IETF 94, the authors defined the following priorities: 1)Detect the problem 2)Report the problem This alerts the network operator to the existence of a conflict so that the configuration error can be corrected. 3)Define consistent behavior This avoids mis-forwarding while the conflict exists. 4)Don't overengineer the solution Given that it is impossible to know which of the conflicting entries is the correct one, we should apply a simple algorithm to resolve the confl= ict. 5)Agree on the resolution behavior The resolution behavior was deliberately the last point because it was considered the least important. Input was received over the past year which emphasized the importance of trying to "maximize forwarding" in the presence of conflicts. Subsequent revisions of the draft have tried to address this concern. However the auth= ors have repeatedly stressed that the solution being proposed ("ignore overlap only") was more complex than other offered alternatives and would be more difficult to guarantee interoperability because subtle differences in an implementation could produce different results. At IETF97 significant feedback was received preferring a simpler solution to the problem. The authors are very sympathetic to this feedback and therefore are proposing a solution based on what the draft defines as the "Ignore" policy - where all entries which are in conflict are ignored. We believe th= is is far more desirable and aligns with the priorities listed above. We outline the proposed solution below and would like to receive feedback f= rom the WG before publishing the next revision of the draft. Les (on behalf of the authors) New Proposal In the latest revision of the draft "SRMS Preference" was introduced. This provides a way for a numerical preference to be explicitly associated with = an SRMS advertisement. Using this an operator can indicate which advertisement= is to be preferred when a conflict is present. The authors think this is a use= ful addition and we therefore want to include this in the new solution. The new preference rule used to resolve conflicts is defined as follows: A given mapping entry is compared against all mapping entries in the databa= se with a preference greater than or equal to its own. If there is a conflict, the mapping entry with lower preference is ignored. If two mapping entries = are in conflict and have equal preference then both entries are ignored. Implementation of this policy is defined as follows: Step 1: Within a single address-family/algorithm/topology sort entries based on preference Step 2: Starting with the lowest preference entries, resolve prefix conflic= ts using the above preference rule. The output is an active policy per topolog= y. Step 3: Take the outputs from Step 2 and again sort them by preference Step 4: Starting with the lowest preference entries, resolve SID conflicts using the above preference rule The output from Step 4 is then the current Active Policy. Here are a few examples. Each mapping entry is represented by the tuple: (Preference, Prefix/mask Index range <#>) Example 1: 1. (150, 1.1.1.1/32 100 range 100) 2. (149, 1.1.1.10/32 200 range 200) 3. (148, 1.1.1.101/32 500 range 10) Entry 3 conflicts with entry 2, it is ignored. Entry 2 conflicts with entry 1, it is ignored. Active policy: (150, 1.1.1.1/32 100 range 100) Example 2: 1. (150, 1.1.1.1/32 100 range 100) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entry 2, both are marked as ignore. Entry 3 conflicts with entry 2. It is marked as ignore. Entry 4 has no conflicts with any entries Active policy: (150, 2.2.2.1/32 1000 range 1) Example 3: 1. (150, 1.1.1.1/32 100 range 500) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entries 2, 3, and 4. All entries are marked ignore. Active policy: Empty Example 4: 1. (150, 1.1.1.1/32 100 range 10) 2. (149, 1.1.1.10/32 200 range 300) 3. (149, 1.1.1.101/32 500 range 10) 4. (148, 2.2.2.1/32 1000 range 1) Entry 4 conflicts with entry 2. It is marked ignore. Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore. Active policy: (150, 1.1.1.1/32 100 range 10) ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ECE79C3OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An even= simpler proposal for the prefix conflict:

&n= bsp;

- if a = SID is attached to the prefix (Prefix-SID Sub-TLV) use it.

- IOW, prefix-SID have precedence over Mapping Server= advertisements. (note that this was the original text, a few years back in= the IGP drafts)

 &= nbsp;           &nbs= p;  - This looks pretty simple as this is about disregarding (in fact = not even looking at) MS entries.

 

- other= wise looks for MS entries

 &= nbsp;           &nbs= p;  - there should be few since they are compressed using the “r= ange” field, so there should not be “scalability issues”<= o:p>

 &= nbsp;           &nbs= p;  - if this is still too complex to look for MS entries and pick one= , I suppose that the Quarantine algo could be used on the MS entries (at le= ast SR capable nodes would not suffer from the conflict, and their proportion should increase over time).

&n= bsp;

This wo= uld clearly simplify the draft, which is what you are calling for: no need = to introduce the following complexities: “Generalized Mapping entry&#= 8221;, “derived mapping entries” and their associated complexity. As a consequence, this would also simplify the discussion in t= he WG.

&n= bsp;

Additio= nal advantages are:

- imple= mentations would not be mandated to support the Mapping Server at all (neit= her server nor client side). This is interesting for vendors not having dep= loyment case mandating LDP interworking. (e.g. greenfield deployment, possibly DC environment, mono-vendor networks= )

- adver= tisement from SR nodes are always used and do not conflict. As time goes, w= e should expect that the proportion of SR compatible nodes increase, which = in the long run favor the simple rule (don’t even consider SRMS) and the absence of conflict (while with S= RMS, we have, by design, multiple advertisements covering the same prefix: = 2 SRMS advertisements for redundancy, plus Prefix SID for SR nodes. Hence c= hance to have conflict in case not all configurations are equals)

- in th= e long run, we could deprecate MS entries and SR-LDP interworking, with no = impact on the selection rules/selected entries.

&n= bsp;

Regards= ,

--Bruno=

&n= bsp;

From: spring [ma= ilto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, December 05, 2016 1:04 AM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal

 

When the problem addressed b= y draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the au= thors defined the following priorities:

 

1)Detect the problem

2)Report the problem

This alerts the network oper= ator to the existence of a conflict so that

the configuration error can = be corrected.

3)Define consistent behavior=

This avoids mis-forwarding w= hile the conflict exists.

4)Don’t overengineer t= he solution

Given that it is impossible = to know which of the conflicting entries

is the correct one, we shoul= d apply a simple algorithm to resolve the conflict.

5)Agree on the resolution be= havior

 

The resolution behavior was = deliberately the last point because it was

considered the least importa= nt.

 

Input was received over the = past year which emphasized the importance of

trying to "maximize for= warding" in the presence of conflicts. Subsequent

revisions of the draft have = tried to address this concern. However the authors

have repeatedly stressed tha= t the solution being proposed

("ignore overlap only&q= uot;) was more complex than other offered alternatives and

would be more difficult to g= uarantee interoperability because subtle

differences in an implementa= tion could produce different results.

 

At IETF97 significant feedba= ck was received preferring a simpler solution to

the problem. The authors are= very sympathetic to this feedback and therefore

are proposing a solution bas= ed on what the draft defines as the "Ignore"

policy - where all entries w= hich are in conflict are ignored. We believe this

is far more desirable and al= igns with the priorities listed above.

 

We outline the proposed solu= tion below and would like to receive feedback from

the WG before publishing the= next revision of the draft.

 

   Les (on behalf = of the authors)

 

New Proposal

 <= /i>

In the latest revision of= the draft "SRMS Preference" was introduced. This

provides a way for a nume= rical preference to be explicitly associated with an

SRMS advertisement. Using= this an operator can indicate which advertisement is

to be preferred when a co= nflict is present. The authors think this is a useful

addition and we therefore= want to include this in the new solution.

 <= /i>

The new preference rule u= sed to resolve conflicts is defined as follows:

 <= /i>

A given mapping entry = is compared against all mapping entries in the database

with a preference grea= ter than or equal to its own. If there is a conflict,

the mapping entry with= lower preference is ignored. If two mapping entries are<= /i>

in conflict and have e= qual preference then both entries are ignored.

 <= /i>

Implementation of this po= licy is defined as follows:

 <= /i>

Step 1: Within a singl= e address-family/algorithm/topology sort entries

based on preference

Step 2: Starting with = the lowest preference entries, resolve prefix conflicts

using the above prefer= ence rule. The output is an active policy per topology.

Step 3: Take the outpu= ts from Step 2 and again sort them by preference

Step 4: Starting with = the lowest preference entries, resolve SID conflicts

using the above prefer= ence rule

 

The output from Step 4= is then the current Active Policy.

 

Here are a few examples. Eac= h mapping entry is represented by the tuple:

(Preference, Prefix/mask Ind= ex range <#>)

 

Example 1:=

 

1. (150, 1.1.1.1/32 100 rang= e 100)

2. (149, 1.1.1.10/32 200 ran= ge 200)

3. (148, 1.1.1.101/32 500 ra= nge 10)

 

Entry 3 conflicts with entry= 2, it is ignored.

Entry 2 conflicts with entry= 1, it is ignored.

Active policy:

 

(150, 1.1.1.1/32 100 range 1= 00)

 

Example 2:=

 

1. (150, 1.1.1.1/32 100 rang= e 100)

2. (150, 1.1.1.10/32 200 ran= ge 200)

3. (150, 1.1.1.101/32 500 ra= nge 10)

4. (150, 2.2.2.1/32 1000 ran= ge 1)

 

Entry 1 conflicts with entry= 2, both are marked as ignore.

Entry 3 conflicts with entry= 2. It is marked as ignore.

Entry 4 has no conflicts wit= h any entries

 

Active policy:

(150, 2.2.2.1/32 1000 range = 1)

 

Example 3:=

 

1. (150, 1.1.1.1/32 100 rang= e 500)

2. (150, 1.1.1.10/32 200 ran= ge 200)

3. (150, 1.1.1.101/32 500 ra= nge 10)

4. (150, 2.2.2.1/32 1000 ran= ge 1)

 

Entry 1 conflicts with entri= es 2, 3, and  4. All entries are marked ignore.

 

Active policy:

Empty

 

Example 4:=

 

1. (150, 1.1.1.1/32 100 rang= e 10)

2. (149, 1.1.1.10/32 200 ran= ge 300)

3. (149, 1.1.1.101/32 500 ra= nge 10)

4. (148, 2.2.2.1/32 1000 ran= ge 1)

 

Entry 4 conflicts with entry= 2. It is marked ignore.

Entry 2 conflicts with entry= 3. Entries 2 and 3 are marked ignore.

 

Active policy:

(150, 1.1.1.1/32 100 range 1= 0)

 

 

 

 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A1ECE79C3OPEXCLILM21corp_-- From nobody Fri Jan 6 10:35:42 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 6A2281295C8; Fri, 6 Jan 2017 10:35:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148372773742.17422.16820307587566514065.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2017 10:35:37 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-05.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:35:37 -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 interworking with LDP Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Filename : draft-ietf-spring-segment-routing-ldp-interop-05.txt Pages : 20 Date : 2017-01-06 Abstract: A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This drafts describes how Segment Routing operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-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 Fri Jan 6 10:46:46 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 2CAE9129D83; Fri, 6 Jan 2017 10:46:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148372840217.17537.9544063973762393466.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2017 10:46:42 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-06.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:46:42 -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 with MPLS data plane Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Martin Horneffer Rob Shakir Jeff Tantsura Edward Crabbe Filename : draft-ietf-spring-segment-routing-mpls-06.txt Pages : 15 Date : 2017-01-06 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change in the forwarding plane. This drafts describes how Segment Routing operates on top of the MPLS data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 9 15:53: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 5D3861299A8 for ; Mon, 9 Jan 2017 15:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPeCI4Wsx7sq for ; Mon, 9 Jan 2017 15:53:27 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 E657B12965A for ; Mon, 9 Jan 2017 15:53:26 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id A553E8FA47BCA; Mon, 9 Jan 2017 23:53:22 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id v09NrOqX025113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2017 23:53:25 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id v09NqLm0029409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jan 2017 23:53:24 GMT Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.176]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0301.000; Mon, 9 Jan 2017 18:53:04 -0500 From: "Aissaoui, Mustapha (Nokia - CA)" To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: SID Conflict Resolution: A Simpler Proposal Thread-Index: AdJOibcaOvA8JiDrT2eiOTpEk40qzwDAodWgAC/MMoAChMj6cAAKwMEwACcyuzAByc3HIAGglL7A Date: Mon, 9 Jan 2017 23:53:03 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340DD4B29211@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <84fe7b43d5054712abf09b274bc3c471@XCH-ALN-001.cisco.com> <4A79394211F1AF4EB57D998426C9340DD4AFFBBF@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340DD4B100A7@US70UWXCHMBA01.zam.alcatel-lucent.com> <63a79609cc964132a1f67cb75da98cf7@XCH-ALN-001.cisco.com> <4A79394211F1AF4EB57D998426C9340DD4B115EF@US70UWXCHMBA01.zam.alcatel-lucent.com> <41bfb2542a984dc29ef0b99fecf06de2@XCH-ALN-001.cisco.com> In-Reply-To: <41bfb2542a984dc29ef0b99fecf06de2@XCH-ALN-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340DD4B29211US70UWXCHMBA01z_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jan 2017 23:53:31 -0000 --_000_4A79394211F1AF4EB57D998426C9340DD4B29211US70UWXCHMBA01z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Les, I am supporting the "ignore overlap only" policy. The reason I am bringing = the "per-prefix resolution" in this discussion is because the SID conflict = resolution happens naturally in 2 steps as part of the prefix resolution: 1. First resolve SID conflicts of the same prefix. 2. Then, resolve SID conflicts across prefixes. This way, all the SIDs associated with a given prefix are first evaluated a= nd a value is chosen. Then if multiple prefixes from step (1) have conflicting SIDs then install = a single SID only in step (2). We just need simple rules to make the selection within each step. I agree that the "ignore" policy is simpler as it does not have to worry ab= out a selection algorithm but it seems to me it will lead to unnecessary lo= ss of SR forwarding capability. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, January 01, 2017 12:15 PM To: Aissaoui, Mustapha (Nokia - CA) ; spring@i= etf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Mustapha - Some responses inline, but I emphasize again that the most important issue = being discussed at the moment is what to do when conflicts are detected. Th= ere are two proposals: 1)Do not use the SIDs which are in conflict ("Ignore") 2)Use some conflict resolution algorithm to choose how to use the conflicti= ng SIDs ("Ignore overlap only") I would encourage you and everyone else to comment on that. If we choose #2 above then the specific preference rule (currently defined = in Section 3.3.4 of the draft) can be reviewed - but not much point in doin= g so until we decide whether we are going to use a preference rule at all. From: Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissaoui@nokia.com] Sent: Friday, December 23, 2016 6:59 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Hi Les, I made some follow-up inline. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Thursday, December 22, 2016 2:37 PM To: Aissaoui, Mustapha (Nokia - CA) >; spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Mustapha - From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Nokia - CA) Sent: Thursday, December 22, 2016 8:10 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal Hi Les, I read slides 17-21 of the document you referenced below and I have the fol= lowing comments: 1. Page 17, "Order Matters - Prefix vs SID Conflict". When you perform resolution on a per prefix basis, prefix conflicts are na= turally processed first followed by SID conflicts across different prefixes= . So the ordering issue described is only specific if you decided to resolv= e conflicting SID entries outside of the natural prefix resolution by a rou= ter. [Les:] What may seem "natural" to you might not to someone else. I don't ca= re to debate that point. What is being illustrated here is that in order to= provide a normative specification that - if followed - guarantees interope= rability we have to specify the order in which conflicts are processed othe= rwise different results may be obtained. MA> I agree on the intent of specifying a procedure which achieves interope= rability. However, it seems to me this draft is ignoring the fact that rout= ers do per-prefix resolution and is trying to perform the SID resolution ou= tside of it. [Les2:] Section 3.2 of the draft details the types of conflicts which may o= ccur. These include: 1)Prefix conflicts - different SIDs assigned to the same prefix 2)SID conflicts - multiple prefixes associated with the same SID The term "pre-prefix resolution" suggests to me that you think all we have = to do is find all the SID advertisements associated with a given prefix in = order to determine whether we have a conflict or not. But that only finds "= prefix conflicts" - it does not find SID conflicts - and both have to be de= alt with. If you mean something else please clarify. 2. Page 18, "Order Matters: Derived vs non-derived- prefix conflict". It seems to me this issue is an artifact of the specific algorithm used to = resolve conflicts. Because the algorithm uses parameters such as "Range (st= art w smallest)" then obviously derived SRMS entries will lend a different = result than original SRMS entries. With the pre-prefix resolution, the only information kept from the original= SRMS entry is the preference and the advertising or owner router. Anything= else is not used. It seems to me a simple algorithm based on preference fi= rst then followed by some rule on selecting the advertising router if confl= icts exist within the same preference would work. [Les:] You have implemented things in a certain way. Someone else might cho= ose to implement in a different way. A normative specification does not (an= d should not) constrain an implementation. What is being illustrated here i= s that if the implementation does not retain the underived entry (in whatev= er internal form it chooses) different results will be obtained because the= preference algorithm depends on comparing the underived ranges. MA> I do not believe this is about implementation. It is about what routers= do and that is resolution per prefix. It does not matter how the prefix SI= D information is advertised, individually or part of an SRMS entry, at the = end it is associated with a prefix. 3. Finally, there is something which has not been addressed in the slid= es. There is still a possibility of conflicting entries among SIDs advertis= ed using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or = OSPF Extended Prefix TLV). A simple rule selecting the advertising router s= hould also work fine here. [Les:] No - source of an advertisement has been quite deliberately excluded= from the preference algorithm. With redistribution/route leaking the sourc= e of an advertisement may appear to be different on different routers- this= would result in different results on different routers. MA> The following RFC is specifying an optional attribute (the IPv4/IPv6 So= urce Router ID TLV) to encode the original advertising router of a prefix. = This can be used to perform a simple selection algorithm: https://tools.ietf.org/html/rfc7794#section-2.2 Otherwise, what is your proposal for this point (3)? I could not find it ad= dressed in the current version of the draft. [Les2:] The proposal is NOT to use the source of an advertisement as an inp= ut to conflict resolution. RFC 7794 only addresses the issue for IS-IS and even then only for SIDs lea= rned via prefix reachability advertisements. Use of source still has consis= tency issues for SRMS advertisements, OSPF, and cases which involve multipl= e protocol instances. This choice has been consciously made and is in part based on our experienc= e with existing implementations. That said, this issue is only relevant if you believe it is necessary/desir= able to use a preference rule to make a choice when a conflict exists. The proponents of "Ignore" don't want to do this - we want to NOT use SIDs = which are in conflict. We believe this is less likely to lead to interopera= bility problems and is less likely to have undesirable side effects. It als= o prioritizes detection and reporting of conflicts. Les Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Friday, December 09, 2016 1:49 PM To: Aissaoui, Mustapha (Nokia - CA) >; spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal Mustapha - From: Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissaoui@nokia.com] Sent: Friday, December 09, 2016 7:44 AM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: RE: SID Conflict Resolution: A Simpler Proposal I have a couple of comments on the below proposal. 1. Regarding the SRMS Preference Sub-TLV in section 3.1 of the draft. I= n many cases, a configuration on the resolving router can assign a preferen= ce to each SRMS in case there is no advertisement of this sub-TLV or to ove= rride an advertised value. I propose that this option be allowed. Here is a= proposed update to the relevant paragraph: " Advertisement of a preference value is optional. Nodes which do= not advertise a preference value are assigned a preference value of 1= 28. A resolving router can override the default or the advertised va= lue by local policy. " [Les:] In order to get consistent conflict resolution on all nodes in the n= etwork, it is necessary that they all have the same database - which includ= es the preference value. If you allow local policy to modify the preference= you no longer have consistent databases on all nodes and we can no longer = guarantee consistent conflict resolution. So your proposal is not viable IM= O. 2. I am trying to understand the concept of sorting SRMS entries which = have different prefixes and different range sizes. Since a SID advertised in a prefix SID sub-TLV within a Prefix TLV (IS-IS I= P Reach TLV or OSPF Extended Prefix TLV) has higher priority over a SID for= the same prefix advertised from a SRMS, then you have to add to the below = sorting an entry for each individual prefix which advertised a prefix SID s= ub-TLV within a prefix TLV. At this point, the concept of an entry with multiple prefixes is moot and y= ou may as well just sort on a per prefix basis which is the most natural th= ing to do given that the prefix resolution and then the SID resolution are = performed on a per prefix basis. SID conflicts can be resolved on a per pre= fix basis using the below proposed preference algorithm without having to i= gnore SID values for unrelated prefixes just because it happens that they w= ere advertised in the same SRMS entry. [Les:] The simpler proposal does not require sorting on anything other than= preference. After that, you can process entries in any order you want and = you will get the same answer. With "Ignore Overlap Only" one of the issues with trying to use the non-con= flicting portions of a mapping entry which has a range > 1 is that the orde= r in which you process entries influences the result. Please see slides 17 = - 20 from the IETF97 presentation: https://www.ietf.org/proceedings/97/slid= es/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pp= tx for some simple examples of this. Les Regards, Mustapha. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Sunday, December 04, 2016 7:04 PM To: spring@ietf.org Subject: [spring] SID Conflict Resolution: A Simpler Proposal When the problem addressed by draft-ietf-spring-conflict-resolution was fir= st presented at IETF 94, the authors defined the following priorities: 1)Detect the problem 2)Report the problem This alerts the network operator to the existence of a conflict so that the configuration error can be corrected. 3)Define consistent behavior This avoids mis-forwarding while the conflict exists. 4)Don't overengineer the solution Given that it is impossible to know which of the conflicting entries is the correct one, we should apply a simple algorithm to resolve the confl= ict. 5)Agree on the resolution behavior The resolution behavior was deliberately the last point because it was considered the least important. Input was received over the past year which emphasized the importance of trying to "maximize forwarding" in the presence of conflicts. Subsequent revisions of the draft have tried to address this concern. However the auth= ors have repeatedly stressed that the solution being proposed ("ignore overlap only") was more complex than other offered alternatives an= d would be more difficult to guarantee interoperability because subtle differences in an implementation could produce different results. At IETF97 significant feedback was received preferring a simpler solution t= o the problem. The authors are very sympathetic to this feedback and therefor= e are proposing a solution based on what the draft defines as the "Ignore" policy - where all entries which are in conflict are ignored. We believe th= is is far more desirable and aligns with the priorities listed above. We outline the proposed solution below and would like to receive feedback f= rom the WG before publishing the next revision of the draft. Les (on behalf of the authors) New Proposal In the latest revision of the draft "SRMS Preference" was introduced. This provides a way for a numerical preference to be explicitly associated with = an SRMS advertisement. Using this an operator can indicate which advertisement= is to be preferred when a conflict is present. The authors think this is a use= ful addition and we therefore want to include this in the new solution. The new preference rule used to resolve conflicts is defined as follows: A given mapping entry is compared against all mapping entries in the databa= se with a preference greater than or equal to its own. If there is a conflict, the mapping entry with lower preference is ignored. If two mapping entries = are in conflict and have equal preference then both entries are ignored. Implementation of this policy is defined as follows: Step 1: Within a single address-family/algorithm/topology sort entries based on preference Step 2: Starting with the lowest preference entries, resolve prefix conflic= ts using the above preference rule. The output is an active policy per topolog= y. Step 3: Take the outputs from Step 2 and again sort them by preference Step 4: Starting with the lowest preference entries, resolve SID conflicts using the above preference rule The output from Step 4 is then the current Active Policy. Here are a few examples. Each mapping entry is represented by the tuple: (Preference, Prefix/mask Index range <#>) Example 1: 1. (150, 1.1.1.1/32 100 range 100) 2. (149, 1.1.1.10/32 200 range 200) 3. (148, 1.1.1.101/32 500 range 10) Entry 3 conflicts with entry 2, it is ignored. Entry 2 conflicts with entry 1, it is ignored. Active policy: (150, 1.1.1.1/32 100 range 100) Example 2: 1. (150, 1.1.1.1/32 100 range 100) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entry 2, both are marked as ignore. Entry 3 conflicts with entry 2. It is marked as ignore. Entry 4 has no conflicts with any entries Active policy: (150, 2.2.2.1/32 1000 range 1) Example 3: 1. (150, 1.1.1.1/32 100 range 500) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entries 2, 3, and 4. All entries are marked ignore. Active policy: Empty Example 4: 1. (150, 1.1.1.1/32 100 range 10) 2. (149, 1.1.1.10/32 200 range 300) 3. (149, 1.1.1.101/32 500 range 10) 4. (148, 2.2.2.1/32 1000 range 1) Entry 4 conflicts with entry 2. It is marked ignore. Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore. Active policy: (150, 1.1.1.1/32 100 range 10) --_000_4A79394211F1AF4EB57D998426C9340DD4B29211US70UWXCHMBA01z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Les,

I am supporting the “ignore overlap only”= policy. The reason I am bringing the “per-prefix resolution” i= n this discussion is because the SID conflict resolution happens naturally in 2 steps as part of the prefix resolution:

1.     First resolve SID conflicts of the same prefi= x.

2.     Then, resolve SID conflicts across prefixes.<= o:p>

 

This way, all the SIDs associated with a given prefix= are first evaluated and a value is chosen.

 

Then if multiple prefixes from step (1) have conflict= ing SIDs then install a single SID only in step (2).

 

We just need simple rules to make the selection withi= n each step.

 

I agree that the “ignore” policy is simpl= er as it does not have to worry about a selection algorithm but it seems to= me it will lead to unnecessary loss of SR forwarding capability.

 

Regards,

Mustapha.

 

From: Les Ginsberg (ginsberg) [mailto:ginsber= g@cisco.com]
Sent: Sunday, January 01, 2017 12:15 PM
To: Aissaoui, Mustapha (Nokia - CA) <mustapha.aissaoui@nokia.com&= gt;; spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /p>

 

Mustapha –<= /o:p>

 

Some responses inline,= but I emphasize again that the most important issue being discussed at the= moment is what to do when conflicts are detected. There are two proposals:=

 

1)Do not use the SIDs = which are in conflict (“Ignore”)

2)Use some conflict re= solution algorithm to choose how to use the conflicting SIDs (“Ignore= overlap only”)

 

I would encourage you = and everyone else to comment on that.

 

If we choose #2 above = then the specific preference rule (currently defined in Section 3.3.4 of th= e draft) can be reviewed – but not much point in doing so until we de= cide whether we are going to use a preference rule at all.

 

From: Aissaoui, Mustapha (Nokia - CA) = [mailto:mustapha.aissaoui@no= kia.com]
Sent: Friday, December 23, 2016 6:59 AM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

Hi Les,

I made some follow-up inline.

 

Regards,

Mustapha.

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Thursday, December 22, 2016 2:37 PM
To: Aissaoui, Mustapha (Nokia - CA) <mustapha.aissaoui@nokia.com>; spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /p>

 

Mustapha -<= /span>

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (Nokia - CA)
Sent: Thursday, December 22, 2016 8:10 AM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

 

Hi Les,

I read slides 17-21 of the document you referenced be= low and I have the following comments:

 

1. = ;    Page 17, “Order Matters - Prefix vs SID Conflict”.

When you perform resolution on  a per pre= fix basis, prefix conflicts are naturally processed first followed by SID c= onflicts across different prefixes. So the ordering issue described is only specific if you decided to resolve conflicting SID= entries outside of the natural prefix resolution by a router.

 

[Les:] What may seem “natural” to you might = not to someone else. I don’t care to debate that point. What is being= illustrated here is that in order to provide a normative specification that – if followed – guarantees interoperability= we have to specify the order in which conflicts are processed otherwise di= fferent results may be obtained.

 

MA> I agree on the intent of specifying a procedur= e which achieves interoperability. However, it seems to me this draft is ig= noring the fact that routers do per-prefix resolution and is trying to perform the SID resolution outside of it.

[Les2:] Section = 3.2 of the draft details the types of conflicts which may occur. These incl= ude:

 

  1)Prefix = conflicts – different SIDs assigned to the same prefix

2)SID conflicts = – multiple prefixes associated with the same SID

 

The term “= pre-prefix resolution” suggests to me that you think all we have to d= o is find all the SID advertisements associated with a given prefix in orde= r to determine whether we have a conflict or not. But that only finds “prefix conflicts” – it does not fin= d SID conflicts – and both have to be dealt with.

If you mean some= thing else please clarify.

 

2. = ;    Page 18, “Order Matters: Derived vs non-derived– prefix c= onflict”.

It seems to me this issue is an artifact of th= e specific algorithm used to resolve conflicts. Because the algorithm uses = parameters such as “Range (start w smallest)” then obviously derived SRMS entries will lend a different result than orig= inal SRMS entries.

With the pre-prefix resolution, the only infor= mation kept from the original SRMS entry is the preference and the advertis= ing or owner router. Anything else is not used. It seems to me a simple algorithm based on preference first then followed = by some rule on selecting the advertising router if conflicts exist within = the same preference would work.

 

[Les:] You have implemented things in a certain way. Som= eone else might choose to implement in a different way. A normative specifi= cation does not (and should not) constrain an implementation. What is being illustrated here is that if the implement= ation does not retain the underived entry (in whatever internal form it cho= oses) different results will be obtained because the preference algorithm d= epends on comparing the underived ranges.

 

MA> I do not beli= eve this is about implementation. It is about what routers do and that is r= esolution per prefix. It does not matter how the prefix SID information is advertised, individually or part of an SRMS entry, at t= he end it is associated with a prefix.

 

3. = ;    Finally, there is something which has not been addressed in the slide= s. There is still a possibility of conflicting entries among SIDs advertise= d using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV). A simple rule select= ing the advertising router should also work fine here.

 

[Les:] No –= ; source of an advertisement has been quite deliberately excluded from the = preference algorithm. With redistribution/route leaking the source of an ad= vertisement may appear to be different on different routers- this would result in different results on different rou= ters.

 

MA> The following RFC is specifying an optional at= tribute (the IPv4/IPv6 Source Router ID TLV) to encode the original adverti= sing router of a prefix. This can be used to perform a simple selection algorithm:

https://tools.ietf.org/html/rfc7794#section-2.2

 

Otherwise, what is your proposal for this point (3)? = I could not find it addressed in the current version of the draft.

 

[Les2:] The prop= osal is NOT to use the source of an advertisement as an input to conflict r= esolution.

RFC 7794 only ad= dresses the issue for IS-IS and even then only for SIDs learned via prefix = reachability advertisements. Use of source still has consistency issues for= SRMS advertisements, OSPF, and cases which involve multiple protocol instances.

This choice has = been consciously made and is in part based on our experience with existing = implementations.

 

That said, this = issue is only relevant if you believe it is necessary/desirable to use a pr= eference rule to make a choice when a conflict exists.

The proponents o= f “Ignore” don’t want to do this – we want to NOT u= se SIDs which are in conflict. We believe this is less likely to lead to in= teroperability problems and is less likely to have undesirable side effects. It also prioritizes detection and reporting of conflicts.

 

   Les=

 

Regards,

Mustapha.

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, December 09, 2016 1:49 PM
To: Aissaoui, Mustapha (Nokia - CA) <mustapha.aissaoui@nokia.com>; spring@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /p>

 

Mustapha -<= /span>

 

From: Aissaoui, Mustapha (Nokia - CA) = [mailto:mustapha.aissaoui@no= kia.com]
Sent: Friday, December 09, 2016 7:44 AM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: RE: SID Conflict Resolution: A Simpler Proposal<= /span>

 

I have a couple of comments on the below proposal.

 

1. = ;    Regarding the SRMS Preference Sub-TLV in section 3.1 of the draft. In= many cases, a configuration on the resolving router can assign a preferenc= e to each SRMS in case there is no advertisement of this sub-TLV or to override an advertised value. I propose that this op= tion be allowed. Here is a proposed update to the relevant paragraph:<= /o:p>

“

           Ad= vertisement of a preference value is optional.  Nodes which do not

          adv= ertise a preference value are assigned a preference value of 128.  &nb= sp;            =         

          &nb= sp;A resolving router can override the default or= the advertised value by local policy.

“

[Les:] In order to get consistent conflict resolution on= all nodes in the network, it is necessary that they all have the same data= base – which includes the preference value. If you allow local policy to modify the preference you no longer have cons= istent databases on all nodes and we can no longer guarantee consistent con= flict resolution. So your proposal is not viable IMO.

 

2. = ;    I am trying to understand the concept of sorting SRMS entries which h= ave different prefixes and different range sizes.  <= /p>

Since a SID advertised in a prefix SID sub-TLV= within a Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV) has h= igher priority over a SID for the same prefix advertised from a SRMS, then you have to add to the below sorting an entry= for each individual prefix which advertised a prefix SID sub-TLV within a = prefix TLV.

At this point, the concept of an entry with mu= ltiple prefixes is moot and you may as well just sort on a per prefix basis= which is the most natural thing to do given that the prefix resolution and then the SID resolution are performed on a per p= refix basis. SID conflicts can be resolved on a per prefix basis using the = below proposed preference algorithm without having to ignore SID values for= unrelated prefixes just because it happens that they were advertised in the same SRMS entry.

 

[Les:] The simpler proposal does not require sorting on = anything other than preference. After that, you can process entries in any = order you want and you will get the same answer.

With “Ignore Overlap Only” one of the issues= with trying to use the non-conflicting portions of a mapping entry which h= as a range > 1 is that the order in which you process entries influences the result. Please see slides 17 – 20 from the IE= TF97 presentation: https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-= ietf-spring-conflict-resolution-02-00.pptx for some simple examples of = this.

 

   Les

 

 

Regards,

Mustapha.

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Sunday, December 04, 2016 7:04 PM
To: spring@ietf.org
Subject: [spring] SID Conflict Resolution: A Simpler Proposal

 

When the problem addressed by draft-ietf-spring-c= onflict-resolution was first

presented at IETF 94, the authors defined the fol= lowing priorities:

 

1)Detect the problem

2)Report the problem

This alerts the network operator to the existence= of a conflict so that

the configuration error can be corrected.

3)Define consistent behavior

This avoids mis-forwarding while the conflict exi= sts.

4)Don’t overengineer the solution

Given that it is impossible to know which of the = conflicting entries

is the correct one, we should apply a simple algo= rithm to resolve the conflict.

5)Agree on the resolution behavior

 

The resolution behavior was deliberately the last= point because it was

considered the least important.

 

Input was received over the past year which empha= sized the importance of

trying to "maximize forwarding" in the = presence of conflicts. Subsequent

revisions of the draft have tried to address this= concern. However the authors

have repeatedly stressed that the solution being = proposed

("ignore overlap only") was more comple= x than other offered alternatives and

would be more difficult to guarantee interoperabi= lity because subtle

differences in an implementation could produce di= fferent results.

 

At IETF97 significant feedback was received prefe= rring a simpler solution to

the problem. The authors are very sympathetic to = this feedback and therefore

are proposing a solution based on what the draft = defines as the "Ignore"

policy - where all entries which are in conflict = are ignored. We believe this

is far more desirable and aligns with the priorit= ies listed above.

 

We outline the proposed solution below and would = like to receive feedback from

the WG before publishing the next revision of the= draft.

 

   Les (on behalf of the authors)<= /o:p>

 

New Proposal

 

In the latest revision of the draft "SRMS= Preference" was introduced. This

provides a way for a numerical preference to b= e explicitly associated with an

SRMS advertisement. Using this an operator can= indicate which advertisement is

to be preferred when a conflict is present. Th= e authors think this is a useful

addition and we therefore want to include this= in the new solution.

 

The new preference rule used to resolve confli= cts is defined as follows:

 

A given mapping entry is compared against a= ll mapping entries in the database

with a preference greater than or equal to = its own. If there is a conflict,

the mapping entry with lower preference is = ignored. If two mapping entries are

in conflict and have equal preference then = both entries are ignored.

 

Implementation of this policy is defined as fo= llows:

 

Step 1: Within a single address-family/algo= rithm/topology sort entries

based on preference

Step 2: Starting with the lowest preference= entries, resolve prefix conflicts

using the above preference rule. The output= is an active policy per topology.

Step 3: Take the outputs from Step 2 and ag= ain sort them by preference

Step 4: Starting with the lowest preference= entries, resolve SID conflicts

using the above preference rule<= /i>

 

The output from Step 4 is then the current = Active Policy.

 

Here are a few examples. Each mapping entry is re= presented by the tuple:

(Preference, Prefix/mask Index range <#>)

 

Example 1:

 

1. (150, 1.1.1.1/32 100 range 100)

2. (149, 1.1.1.10/32 200 range 200)

3. (148, 1.1.1.101/32 500 range 10)

 

Entry 3 conflicts with entry 2, it is ignored.

Entry 2 conflicts with entry 1, it is ignored.

Active policy:

 

(150, 1.1.1.1/32 100 range 100)

 

Example 2:

 

1. (150, 1.1.1.1/32 100 range 100)

2. (150, 1.1.1.10/32 200 range 200)

3. (150, 1.1.1.101/32 500 range 10)

4. (150, 2.2.2.1/32 1000 range 1)

 

Entry 1 conflicts with entry 2, both are marked a= s ignore.

Entry 3 conflicts with entry 2. It is marked as i= gnore.

Entry 4 has no conflicts with any entries

 

Active policy:

(150, 2.2.2.1/32 1000 range 1)

 

Example 3:

 

1. (150, 1.1.1.1/32 100 range 500)

2. (150, 1.1.1.10/32 200 range 200)

3. (150, 1.1.1.101/32 500 range 10)

4. (150, 2.2.2.1/32 1000 range 1)

 

Entry 1 conflicts with entries 2, 3, and  4.= All entries are marked ignore.

 

Active policy:

Empty

 

Example 4:

 

1. (150, 1.1.1.1/32 100 range 10)

2. (149, 1.1.1.10/32 200 range 300)

3. (149, 1.1.1.101/32 500 range 10)

4. (148, 2.2.2.1/32 1000 range 1)

 

Entry 4 conflicts with entry 2. It is marked igno= re.

Entry 2 conflicts with entry 3. Entries 2 and 3 a= re marked ignore.

 

Active policy:

(150, 1.1.1.1/32 100 range 10)

 

 

 

 

--_000_4A79394211F1AF4EB57D998426C9340DD4B29211US70UWXCHMBA01z_-- From nobody Tue Jan 17 08:35:40 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 224B2129982; Tue, 17 Jan 2017 08:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, 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 wIMkUkW1Q3B9; Tue, 17 Jan 2017 08:35:35 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A848B12997F; Tue, 17 Jan 2017 08:35:12 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 3B5781C0903; Tue, 17 Jan 2017 17:35:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 1890280066; Tue, 17 Jan 2017 17:35:11 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Tue, 17 Jan 2017 17:35:10 +0100 From: To: "draft-ietf-spring-oam-usecase@ietf.org" Thread-Topic: draft-ietf-spring-oam-usecase - shepherd review Thread-Index: AdJw331BkrJw6jV3SvW717QgrvEvbg== Date: Tue, 17 Jan 2017 16:35:10 +0000 Message-ID: <22525_1484670911_587E47BF_22525_3663_1_53C29892C857584299CBF5D05346208A1ED013DB@OPEXCLILM21.corporate.adroot.infra.ftgroup> 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_53C29892C857584299CBF5D05346208A1ED013DBOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "spring-chairs@ietf.org" Subject: [spring] draft-ietf-spring-oam-usecase - shepherd review X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jan 2017 16:35:39 -0000 --_000_53C29892C857584299CBF5D05346208A1ED013DBOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi authors, As the document shepherd, I have reviewed draft-ietf-spring-oam-usecase-04. Please find some comments below. Best regards, Bruno --- =3D=3D=3D=3D=3D Major comment Multiple sections or text of the document seems to mix continuity check and= connectivity verification. I think the document would be clearer if both p= oints were more structured. e.g. introducing each, then explaining their in= teractions, then detailing each one independently, possibly in independent = sub-section. =3D=3D=3D=3D=3D Minor comments =A72 "enabling MPLS topology detection based on IGP signaled segments as specifi= ed at [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]." You could probably add draft-ietf-idr-bgp-ls-segment-routing-ext, as an e= xternal server is less likely to be part of the IGP. ---- "As compared to LDP, Segment Routing is expected to simplify the system by = enabling MPLS topology detection based on IGP signaled segments" I find the term "MPLS topology" loosely defined. As I read it, it could enc= ompass: - the network topology, which can be learnt by listening to the IGP, regard= less of the use of LDP or Segment Routing - MPLS signaling topology. With segment routing, it can be learnt by listen= ing to IGP. For LDP, it would require looking at the LDP configuration or L= DP status. - MPLS signaled labels. With segment routing, it can be learnt by listening= to IGP. For LDP, it would require one T-LDP session per node. Could you please elaborate on what is exactly meant with "MPLS topology"? --- One paragraph is about the use of SRMS in LDP network. "The system applies = to monitoring of LDP LSP's ...." Another paragraph is about the use of SRMS in pre-segment routing networks.= "The MPLS path monitoring system described by this document can be realise= d with pre-Segment Routing (SR) based technology." It's not crystal clear to mean what you mean by "pre-Segment Routing (SR) b= ased technology." I could read "LDP", in which case, both paragraph are abo= ut the same subject. In which case, an editorial update would be useful to = merge those two paragraphs, as they are related to the same case. (or at le= ast very related) --- "The system offers several benefits for network monitoring." I would expect those benefits to be spelled out in the document. The senten= ce is indeed followed by a set of sentences, but it's not clear to me wheth= er those sentences details those benefits or not. The first two sentences l= ooks like benefits. The third one ["MPLS path trace function (whose specifi= cation and features are not part of this use case) is required, if the actu= al data plane of a router should be checked against its control plane.]", d= oes not looks like a benefit to me. Could you please highlight which are the specific benefits? --- "MPLS path trace function (whose specification and features are not part of this use case) is required, if the actual data plane of a router should be checked against its control plane." That sentence is 2 years old. Since then, has the MPLS WG progressed on thi= s? If so, could you please indicate the related draft. If not, why? And is this related to a further paragraph: " Documents discussing SR OAM requirements and possible solutions to allow SR usage as described by this document have been submitted already, see [I-D.ietf-spring-sr-oam-requirement] and [I-D.ietf-mpls-spring-lsp-ping]." If so, both could probably be merged. Any may be "already" is not appropriate for an RFC. --- >From an editorial standpoint, I feel that the text mixes: - the monitoring part, which is expected to be forwarded in the dataplane j= ust like users packets. - the trace/OAM features, which requires specific features on transit nodes= , hence are not forwarded in the dataplane like users packets. May be those 2 functions could be better distinguished in the text. --- "By utilising the ECMP related tool set offered e.g. by RFC 4379 [RFC4379],= a segment based routing LSP monitoring system may: o easily detect ECMP functionality and properties of paths at data leve= l." It's not clear to me what is meant by "properties" nor "at data level". Regarding detecting ECMP functionality, it could be detected with SR IGP ex= tensions, both for layer 3 ECMP (adj_SID) and layer 2 ECMP (draft-ietf-isi= s-l2bundles). Or may be you mean load-balancing behavior over ECMP links/path. But this i= s not what is written. --- "limit the MPLS label stack of an OAM packet to a minmum of 3 labels." Do you mean :s/minmum/maximum Why is this important? - If this is a hard limitation on the SRMS, then the probing packets would = also need to have a max of 3 labels. Which is typically not achievable. - Why would the SRMS have such a limitation for a pure software based featu= re? --- "It doesn't have to support any specialised protocol stack," What do you mean by this? It does need to support the MPLS protocol stack, probably the IP protocol s= tack, the IGP protocol stack in order to learn the topology/labels, the LSP= Ping protocol stack if OAM test are required.... --- "The MPLS monitoring servers are the single entities pushing monitoring pac= ket label stacks." may be :s/single/only :s/pushing/sending and receiving --- "If the depth of label stacks to be pushed by a path monitoring system (PMS) are of concern for a domain, a dedicated server based path monitoring architecture allows limiting monitoring related label stack pushes to these servers." If the limitation is on the PMS, as already expressed I don't see why a pur= e software packet sender would be limited in term of the number of labels (= which are just bytes) sent. If the limitation is elsewhere, could you pleas= e elaborate. The second part of the sentence could be rephrased for an easier understand= ing. (it took me 3 readings to guess that the important part is running the= PMS on dedicated server. Although I'm even sure why using a software on a = server solves the problem compared to using a software on the routing engin= e of a router (which may also be x86). --- =A73 "It can send pure monitoring packets" What do you mean by "pure"? >From the next sentence, I'd guess that you mean "monitoring packets with an= y payload" --- "Segment Routing here is used as a means of adding label stacks and hence transport to standard MPLS OAM packets, which then detect correspondence of control and data plane of this (or any other addressed) path." Could probably be better rephrased. e.g. Segment Routing here is used as a mean of transporting probes or standard M= PLS OAM packets, along any path. When MPLS OAM packets are used, consist= ency between control and data plane may be checked. --- "if the PMS is an IP host not connected to the MPLS domain, the PMS can send its probe with the list of SIDs/Labels onto a suitable tunnel providing an MPLS access to a router which is part of the monitored MPLS domain." Probably some text should be added to cover this point. (e.g. the tunnel MU= ST be secured and provide authentication of the sender and cryptographic si= gnature. Also this has security implication as MPLS VPNs are based on the inability = of the sender to send MPLS packet, while this option open this door. This s= hould be discussed in the security consideration section. ---- =A74.1 "To be able to work with the smallest possible SR label stack, first a suit= able MPLS OAM method is used to detect the ECMP routed path between LER i t= o LER j which is to be monitored " This is not very clear to me. Could this be rephrased? e.g. What to do mean= by "MPLS OAM method?" Is this MPLS OAM API (e.g. LSP ping)? Is this an alg= orithm to define the path? (but the end of the sentence seems to indicate t= hat the path is given as input "which is to be monitored") is "detect" the = best term? Also, this really the first sentence of the section. Could you first introd= uce the global picture and the goal, rather than starting with an optimisat= ion "To be able to work with the smallest possible SR label stack" --- "The packet will only reliably use the monitored path, if the label and address information used in combination with the MPLS OAM method of choice is identical to that of the monitoring packet." Could this be rephrased to improve clarity? ---- "The path PMS to LER i must be available." "The path LER j to PMS must be a= vailable." Given that the goal is to monitor paths which are assumed to be available, = if you detect a packet loss, how do you know which segment has an error? In= deed, packet loss could happen on this PMS to LERi path, while you think th= at you are measuring the path LER i to LER j. --- "This path must be detectable" What does this mean? --- "If ECMP is deployed, it may be desired to measure along both possible path= s which a packet may use between LER i and LER j." - ECMP may be more than both. - If you don't want to follow an ECMP path, why are you sending packet alon= g an ECMP path? SR allows enforcing a single path among multiple ECMPs. ---- "Further changes in ECMP functionality at LER i will impact results." Can you elaborate on this? Some LSR dynamically change their load-balancing= behavior in order to try to equally spread the load on all ECMP paths. Is = this behavior an issue? (i.e. are PMS and dynamic load-balancing adaptation= mutually incompatible?) Also if you want to monitor the (customer) ECMP path, would it be good to d= etect any change in this path, including a change trigger by such dynamic l= oad-balancing adaptation? And if you don't want to monitor the ECMP path, may be you should only moni= tor individual path. ---- " Determining a path to be executed prior to a measurement may also be done by setting up a label stack including all Node SIDs along that path (if LSR1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities." Adding all node SID do not remove ECMP functionnality. e.g. there could = be multiple links between LSR1 and LER i. --- "Monitoring an MPLS domain by a PMS based on SR offers the option of monitoring complete MPLS domains with little effort and very excellent scalability." Why is the scalability excellent? It looks to me that some links near the P= MS will be "heavily" used to test all paths. "little effort" is not very specific. IMHO a key benefit is the ability to = monitor all network paths by deploying a single PMS, while some others tech= niques requires the deployment of many probes. --- "The PMS does not require access to LSR/LER management interfaces " The choice of the term "interfaces" seems debatble to me as it could be mis= read as physical interface being monitored. As the goal of this document is= to monitor path and interfaces, I'd rather use "interface" only to refer t= o physical interface. --- =A74.2 Same comment: if the PMS detects loss of probe packets, it does not know wh= ether the loss happens on the monitored bundle, or the path from the PMS to= R2 or the path from R1 to the PMS. So how do you compute/measure the characteristics of the sub-path (here the= bundle) that you want to monitor? --- =A74.3 "In the previous example, a uni-directional fault on the middle link in direction of R2 to R1 would be localized by sending the following two probes with respective segment lists: o 72, 662, 992, 664 o 72, 663, 992, 664" "The first probe would fail while the second would succeed." I would have said the opposite as 663 maps to the middle link which is assu= med to be faulty. The formulation of the text is debatable as you are using the a priori know= nledge of the failure in order to define the probes which needs to be sent. More generally, as you are sending packets over a path longer than the one = to be tested, what you need is to also monitor those extra sub-path in orde= r to be able to check whether the failure is indeed on the sub-path that yo= u want to test, rather than the paths from the PMS to the first node on the= tested path, or the path from the last node on the tested path to the PMS. --- =A76 "Next: LDP or RSVP-TE label identifying the path to LER j at LER i. if LER j is the ingress of the RSVP-TE LSP, LER j does not have a label ide= ntifying this LSP. Eventually, SR may allocate a binding SID to this RSVP-T= E LSP. if LER j is a transit LSR of the RSVP-TE LSP, how does the PMS learn this l= abels, which a priori is only know from LER j and its upstream LSR. --- =A77 " MPLS SR topology awareness should allow the SID to monitor liveliness of most types of SIDs (this may not be recommendable if a SID identifies an inter domain interface)" Why would it not be recommendable to monitor an inter domain SID/interface? --- "To match control plane information with data plane information, MPLS OAM functions as defined for example by RFC 4379 [RFC4379] should be enhanced to allow collection of data relevant to check all relevant types of Segment IDs." Is there a document working on this? (e.g. draft-ietf-mpls-spring-lsp-ping = ?) If so, it could be referenced. --- =A78 "While the PMS based use cases explained in Section 3 " I think uses-cases are explained in section 4. --- =A76 "An implementation report on a PMS operating in an LDP domain is given in [= I-D.leipnitz-spring-pms-implementation-report]" This document is more than an implementation. IMHO it would deserve a short= text introducing its scope and result. e.g. "[I-D.leipnitz-spring-pms-implementation-report] present a PMS implementati= on report and compare delays measured with one PMS to the results of three = IPPM standard conformant Measurement Agents, using the IPPM methodology as = defined in [RFC6576]. The results show that the PMS measurements equal those captured by an IPPM conformant measurement system. The ADK test is successful by comparing the measurement values of the round-trip delays for packets with a size of 64 bytes." (but I'm not an IPPM expert, so authors should be able to provide a better = text) =3D=3D=3D=3D=3D Nits "IGP LSA" LSA is not defined nor expanded on first use. Plus it is protocol specific (OSPF). Could you cover both OSPF and IS-IS or= use a term which is not protocol specific? Especially since a priori you m= ean LSDB analysis, rather than LSA. --- :s/minmum/minimum --- OLD: used as a means of adding label stacks and hence transport to standard= MPLS OAM packets NEW: used as a mean of adding label stacks and hence transport standard MPL= S OAM packets to any node ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ED013DBOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi authors,

 

As the document shepherd, I hav= e reviewed draft-ietf-spring-oam-usecase-04.

Please find some comments below= .

 

Best regards,=

Bruno

---

 

=3D=3D=3D=3D=3D Major comment

Multiple sections or text of th= e document seems to mix continuity check and connectivity verification. I t= hink the document would be clearer if both points were more structured. e.g= . introducing each, then explaining their interactions, then detailing each one independently, possibly in ind= ependent sub-section.

 

=3D=3D=3D=3D=3D Minor comments<= o:p>

=A72

"enabling MPLS topology de= tection based on IGP signaled segments as specified at [I-D.ietf-isis-segme= nt-routing-extensions] and

   [I-D.ietf-ospf-seg= ment-routing-extensions]."

You could probably add &nb= sp; draft-ietf-idr-bgp-ls-segment-routing-ext, as an external server is les= s likely to be part of the IGP.

 

----

"As compared to LDP, Segme= nt Routing is expected to simplify the system by enabling MPLS topology det= ection based on IGP signaled segments"

I find the term "MPLS topo= logy" loosely defined. As I read it, it could encompass:

- the network topology, which c= an be learnt by listening to the IGP, regardless of the use of LDP or Segme= nt Routing

- MPLS signaling topology. With= segment routing, it can be learnt by listening to IGP. For LDP, it would r= equire looking at the LDP configuration or LDP status.

- MPLS signaled labels. With se= gment routing, it can be learnt by listening to IGP. For LDP, it would requ= ire one T-LDP session per node.

 

Could you please elaborate on w= hat is exactly meant with "MPLS topology"?

 

---

One paragraph is about the use = of SRMS in LDP network. "The system applies to monitoring of LDP LSP's= ...."

Another paragraph is about the = use of SRMS in pre-segment routing networks. "The MPLS path monitoring= system described by this document can be realised with pre-Segment Routing= (SR) based technology."

 

It's not crystal clear to mean = what you mean by "pre-Segment Routing (SR) based technology." I c= ould read "LDP", in which case, both paragraph are about the same= subject. In which case, an editorial update would be useful to merge those two paragraphs, as they are related to the same case. (or a= t least very related)

 

---

"The system offers several= benefits for network monitoring."

I would expect those benefits t= o be spelled out in the document. The sentence is indeed followed by a set = of sentences, but it's not clear to me whether those sentences details thos= e benefits or not. The first two sentences looks like benefits. The third one ["MPLS path trace function (whose = specification and features are not part of this use case) is required, if t= he actual data plane of a router should be checked against its control plan= e.]", does not looks like a benefit to me.

Could you please highlight whic= h are the specific benefits?

 

---

"MPLS path trace function = (whose specification and features

   are not part of th= is use case) is required, if the actual data plane

   of a router should= be checked against its control plane."

 

That sentence is 2 years old. S= ince then, has the MPLS WG progressed on this? If so, could you please indi= cate the related draft. If not, why?

 

And is this related to a furthe= r paragraph:

"   Documents di= scussing SR OAM requirements and possible solutions to

   allow SR usage as = described by this document have been submitted

   already, see [I-D.= ietf-spring-sr-oam-requirement] and

   [I-D.ietf-mpls-spr= ing-lsp-ping]."

   =

If so, both could probably be m= erged.

Any may be "already" = is not appropriate for an RFC.

 

---

From an editorial standpoint, I= feel that the text mixes:

- the monitoring part, which is= expected to be forwarded in the dataplane just like users packets.

- the trace/OAM features, which= requires specific features on transit nodes, hence are not forwarded in th= e dataplane like users packets.

 

May be those 2 functions could = be better distinguished in the text.

 

---

"By utilising the ECMP rel= ated tool set offered e.g. by RFC 4379 [RFC4379], a segment based routing L= SP monitoring system may:

   o  easily det= ect ECMP functionality and properties of paths at data level."

It's not clear to me what is me= ant by "properties"  nor "at data level".

Regarding detecting ECMP functi= onality, it could be detected with SR IGP extensions, both for layer 3 ECMP= (adj_SID)  and layer 2 ECMP (draft-ietf-isis-l2bundles).

Or may be you mean load-balanci= ng behavior over ECMP links/path. But this is not what is written.

 

---

"limit the MPLS label stac= k of an OAM packet to a minmum of 3 labels."

Do you mean :s/minmum/maximum <= o:p>

 

Why is this important?

- If this is a hard limitation = on the SRMS, then the probing packets would also need to have a max of 3 la= bels. Which is typically not achievable.

- Why would the SRMS have such = a limitation for a pure software based feature?

 

---

"It doesn't have to suppor= t any specialised protocol stack,"

What do you mean by this? =

It does need to support the MPL= S protocol stack, probably the IP protocol stack, the IGP protocol stack in= order to learn the topology/labels, the LSP Ping protocol stack if OAM tes= t are required....

 

---

"The MPLS monitoring serve= rs are the single entities pushing monitoring packet label stacks."

may be

:s/single/only

:s/pushing/sending and receivin= g

 

---

"If the depth

   of label stacks to= be pushed by a path monitoring system (PMS) are of

   concern for a doma= in, a dedicated server based path monitoring

   architecture allow= s limiting monitoring related label stack pushes to

   these servers.&quo= t;

   =

If the limitation is on the PMS= , as already expressed I don't see why a pure software packet sender would = be limited in term of the number of labels (which are just bytes) sent. If = the limitation is elsewhere, could you please elaborate.

The second part of the sentence= could be rephrased for an easier understanding. (it took me 3 readings to = guess that the important part is running the PMS on dedicated server. Altho= ugh I'm even sure why using a software on a server solves the problem compared to using a software on the routing= engine of a router (which may also be x86).

 

---

=A73

"It can send pure monitori= ng packets"

What do you mean by "pure&= quot;?

From the next sentence, I'd gue= ss that you mean "monitoring packets with any payload"=

---

"Segment=

   Routing here is us= ed as a means of adding label stacks and hence

   transport to stand= ard MPLS OAM packets, which then detect

   correspondence of = control and data plane of this (or any other

   addressed) path.&q= uot;

   =

Could probably be better rephra= sed. e.g.   

 

Segment Routing here is used as= a mean of transporting probes or standard MPLS OAM packets, along any path= . When MPLS OAM packets are used,    consistency between con= trol and data plane may be checked.

 

---

"if the PMS is an IP host = not connected to the MPLS domain,

   the PMS can send i= ts probe with the list of SIDs/Labels onto a

   suitable tunnel pr= oviding an MPLS access to a router which is part of

   the monitored MPLS= domain."

 

Probably some text should be ad= ded to cover this point. (e.g. the tunnel MUST be secured and provide authe= ntication of the sender and cryptographic signature.

Also this has security implicat= ion as MPLS VPNs are based on the inability of the sender to send MPLS pack= et, while this option open this door. This should be discussed in the secur= ity consideration section.

 

----

=A74.1

 

"To be able to work with t= he smallest possible SR label stack, first a suitable MPLS OAM method is us= ed to detect the ECMP routed path between LER i to LER j which is to be mon= itored "

This is not very clear to me. C= ould this be rephrased? e.g. What to do mean by "MPLS OAM method?"= ; Is this MPLS OAM API (e.g. LSP ping)? Is this an algorithm to define the = path? (but the end of the sentence seems to indicate that the path is given as input "which is to be monitored") is &= quot;detect" the best term?

 

Also, this really the first sen= tence of the section. Could you first introduce the global picture and the = goal, rather than starting with an optimisation "To be able to work wi= th the smallest possible SR label stack"

---

"The packet will

   only reliably use = the monitored path, if the label and address

   information used i= n combination with the MPLS OAM method of choice is

   identical to that = of the monitoring packet."

 

   Could this be reph= rased to improve clarity?  

----  

"The path PMS to LER i mus= t be available." "The path LER j to PMS must be available."

Given that the goal is to monit= or paths which are assumed to be available, if you detect a packet loss, ho= w do you know which segment has an error? Indeed, packet loss could happen = on this PMS to LERi path, while you think that you are measuring the path LER i to LER j.

---

"This path must be detecta= ble"

What does this mean?=

 

---

"If ECMP is deployed, it m= ay be desired to measure along both possible paths which a packet may use b= etween LER i and LER j."

- ECMP may be more than both.

- If you don't want to follow a= n ECMP path, why are you sending packet along an ECMP path? SR allows enfor= cing a single path among multiple ECMPs.

 

----

"Further changes in ECMP f= unctionality at LER i will impact results."

Can you elaborate on this? Some= LSR dynamically change their load-balancing behavior in order to try to eq= ually spread the load on all ECMP paths. Is this behavior an issue? (i.e. a= re PMS and dynamic load-balancing adaptation mutually incompatible?)

Also if you want to monitor the= (customer) ECMP path, would it be good to detect any change in this path, = including a change trigger by such dynamic load-balancing adaptation?<= /o:p>

And if you don't want to monito= r the ECMP path, may be you should only monitor individual path.=

----

"   Determining = a path to be executed prior to a measurement may also be<= /p>

   done by setting up= a label stack including all Node SIDs along that

   path (if LSR1 has = Node SID 40 in the example and it should be passed

   between LER i and = LER j, the label stack is 20 - 40 - 30 - 10).  The

   advantage of this = method is, that it does not involve MPLS OAM

   functionality and = it is independent of ECMP functionalities."

 

   Adding all node SI= D do not remove ECMP functionnality. e.g. there could be multiple links bet= ween LSR1 and LER i.

 

  ---

  "Monitoring an MPLS= domain by a PMS based on SR offers the option of

   monitoring complet= e MPLS domains with little effort and very

   excellent scalabil= ity."

Why is the scalability excellen= t? It looks to me that some links near the PMS will be "heavily" = used to test all paths.

"little effort" is no= t very specific. IMHO a key benefit is the ability to monitor all network p= aths by deploying a single PMS, while some others techniques requires the d= eployment of many probes.

 

---

"The PMS does not require = access to LSR/LER management interfaces "

The choice of the term "in= terfaces" seems debatble to me as it could be misread as physical inte= rface being monitored. As the goal of this document is to monitor path and = interfaces, I'd rather use "interface" only to refer to physical interface.

---

=A74.2

Same comment: if the PMS detect= s loss of probe packets, it does not know whether the loss happens on the m= onitored bundle, or the path from the PMS to R2 or the path from R1 to the = PMS.

So how do you compute/measure t= he characteristics of the sub-path (here the bundle) that you want to monit= or?

---

=A74.3

   "In the = previous example, a uni-directional fault on the middle link

   in direction of R2= to R1 would be localized by sending the following

   two probes with re= spective segment lists:

   o  72, 662, 9= 92, 664

   o  72, 663, 9= 92, 664"

   =

 

"The first probe would fai= l while the second would succeed."

I would have said the opposite = as 663 maps to the middle link which is assumed to be faulty.

 

The formulation of the text is = debatable as you are using the a priori knownledge of the failure in order = to define the probes which needs to be sent.

More generally, as you are send= ing packets over a path longer than the one to be tested, what you need is = to also monitor those extra sub-path in order to be able to check whether t= he failure is indeed on the sub-path that you want to test, rather than the paths from the PMS to the first nod= e on the tested path, or the path from the last node on the tested path to = the PMS.

 

---

=A76

"Next: LDP or RSVP-TE labe= l identifying the path to LER j at LER i.

 

if LER j is the ingress of the = RSVP-TE LSP, LER j does not have a label identifying this LSP. Eventually, = SR may allocate a binding SID to this RSVP-TE LSP.

if LER j is a transit LSR of th= e RSVP-TE LSP, how does the PMS learn this labels, which a priori is only k= now from LER j and its upstream LSR.

 

---

=A77

"   MPLS SR topo= logy awareness should allow the SID to monitor liveliness=

   of most types of S= IDs (this may not be recommendable if a SID

   identifies an inte= r domain interface)"

   =

Why would it not be recommendab= le to monitor an inter domain SID/interface?

---

      = "To match control plane information with data plane information, MPLS<= o:p>

   OAM functions as d= efined for example by RFC 4379 [RFC4379] should be

   enhanced to allow = collection of data relevant to check all relevant

   types of Segment I= Ds."

Is there a document working on = this? (e.g. draft-ietf-mpls-spring-lsp-ping ?) If so, it could be reference= d.

   =

---

=A78

"While the PMS based use c= ases explained in Section 3 "

I think uses-cases are explaine= d in section 4.

---

=A76

"An implementation report = on a PMS operating in an LDP domain is given in [I-D.leipnitz-spring-pms-im= plementation-report]"

This document is more than an i= mplementation. IMHO it would deserve a short text introducing its scope and= result. e.g.

"[I-D.leipnitz-spring-pms-= implementation-report] present a PMS implementation report and compare dela= ys measured with one PMS to the results of three IPPM standard conformant M= easurement Agents, using the IPPM methodology as defined in [RFC6576].

The results show that the PMS m= easurements equal those captured by

   an IPPM conformant= measurement system.  The ADK test is successful by<= /p>

   comparing the meas= urement values of the round-trip delays for packets

   with a size of 64 = bytes."

   =

(but I'm not an IPPM expert, so= authors should be able to provide a better text)  

 

=3D=3D=3D=3D=3D Nits=

"IGP LSA"<= /span>

LSA is not defined nor expanded= on first use.

Plus it is protocol specific (O= SPF). Could you cover both OSPF and IS-IS or use a term which is not protoc= ol specific? Especially since a priori you mean LSDB analysis, rather than = LSA.

---

:s/minmum/minimum

---

OLD: used as a means of adding = label stacks and hence transport to standard MPLS OAM packets

NEW: used as a mean of adding l= abel stacks and hence transport standard MPLS OAM packets to any node<= /o:p>

 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A1ED013DBOPEXCLILM21corp_-- From nobody Tue Jan 17 23:11: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 8F0BF1293E8; Tue, 17 Jan 2017 23:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.518 X-Spam-Level: X-Spam-Status: No, score=-7.518 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 ohBzK7THCIFJ; Tue, 17 Jan 2017 23:11:52 -0800 (PST) Received: from MAILOUT11.telekom.de (MAILOUT11.telekom.de [80.149.113.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91DF120727; Tue, 17 Jan 2017 23:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1484723511; x=1516259511; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=clb4g4oV07BQBlnHNkX5K3++UwKFXfR49soB1EceX/E=; b=sYflxXBhNgM8YTiIYvJbg6P6zLyiRYv2tcN88uV5fVLFP+zpGZtYTTix gqw3hoF5L7/eVv/ooFP+wXYmR+lifAoMh8DfWHQfZblTSL0qslZDVOYly leu4qVsatUyxpYtTe1KPXRkQiKHOfS37PtWDw/Zp92GYwziY6VQZ+E38g sAE/WFQEzwKo2iBkewVCvZHMJny57/GCWnYnrjC0vDlpXpw/4ZO59cuCB 60ckJIO0HqoKQL2fzIUi8vbeNVq20SV5AT4HEdq4YmELJxbN0DcPxcEeg zmpNE0IepTqNNaGmyONlTiCfwcCWZESlVg93PBYZ9ZdL0w1V2EsNGIxfY A==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 18 Jan 2017 08:11:47 +0100 X-IronPort-AV: E=Sophos;i="5.33,248,1477954800"; d="scan'208,217";a="601656095" Received: from he101653.emea1.cds.t-internal.com ([10.134.226.13]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 08:11:39 +0100 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101653.emea1.cds.t-internal.com (10.134.226.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 18 Jan 2017 08:11:38 +0100 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1236.000; Wed, 18 Jan 2017 08:11:38 +0100 From: To: Thread-Topic: draft-ietf-spring-oam-usecase - shepherd review Thread-Index: AdJw331BkrJw6jV3SvW717QgrvEvbgAel+HA Date: Wed, 18 Jan 2017 07:11:38 +0000 Message-ID: References: <22525_1484670911_587E47BF_22525_3663_1_53C29892C857584299CBF5D05346208A1ED013DB@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <22525_1484670911_587E47BF_22525_3663_1_53C29892C857584299CBF5D05346208A1ED013DB@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.164.76] Content-Type: multipart/alternative; boundary="_000_eed31f8f266b467d93867be85c732950HE101653emea1cdstintern_" MIME-Version: 1.0 Archived-At: Cc: spring@ietf.org, spring-chairs@ietf.org, draft-ietf-spring-oam-usecase@ietf.org Subject: Re: [spring] draft-ietf-spring-oam-usecase - shepherd review X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jan 2017 07:11:56 -0000 --_000_eed31f8f266b467d93867be85c732950HE101653emea1cdstintern_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, before reading - thanks for sheperding and thanks for your review. Hope, you had a good start into 2017, Ruediger Von: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Gesendet: Dienstag, 17. Januar 2017 17:35 An: draft-ietf-spring-oam-usecase@ietf.org Cc: spring@ietf.org; spring-chairs@ietf.org Betreff: draft-ietf-spring-oam-usecase - shepherd review Hi authors, As the document shepherd, I have reviewed draft-ietf-spring-oam-usecase-04. Please find some comments below. Best regards, Bruno --- =3D=3D=3D=3D=3D Major comment Multiple sections or text of the document seems to mix continuity check and= connectivity verification. I think the document would be clearer if both p= oints were more structured. e.g. introducing each, then explaining their in= teractions, then detailing each one independently, possibly in independent = sub-section. =3D=3D=3D=3D=3D Minor comments =A72 "enabling MPLS topology detection based on IGP signaled segments as specifi= ed at [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]." You could probably add draft-ietf-idr-bgp-ls-segment-routing-ext, as an e= xternal server is less likely to be part of the IGP. ---- "As compared to LDP, Segment Routing is expected to simplify the system by = enabling MPLS topology detection based on IGP signaled segments" I find the term "MPLS topology" loosely defined. As I read it, it could enc= ompass: - the network topology, which can be learnt by listening to the IGP, regard= less of the use of LDP or Segment Routing - MPLS signaling topology. With segment routing, it can be learnt by listen= ing to IGP. For LDP, it would require looking at the LDP configuration or L= DP status. - MPLS signaled labels. With segment routing, it can be learnt by listening= to IGP. For LDP, it would require one T-LDP session per node. Could you please elaborate on what is exactly meant with "MPLS topology"? --- One paragraph is about the use of SRMS in LDP network. "The system applies = to monitoring of LDP LSP's ...." Another paragraph is about the use of SRMS in pre-segment routing networks.= "The MPLS path monitoring system described by this document can be realise= d with pre-Segment Routing (SR) based technology." It's not crystal clear to mean what you mean by "pre-Segment Routing (SR) b= ased technology." I could read "LDP", in which case, both paragraph are abo= ut the same subject. In which case, an editorial update would be useful to = merge those two paragraphs, as they are related to the same case. (or at le= ast very related) --- "The system offers several benefits for network monitoring." I would expect those benefits to be spelled out in the document. The senten= ce is indeed followed by a set of sentences, but it's not clear to me wheth= er those sentences details those benefits or not. The first two sentences l= ooks like benefits. The third one ["MPLS path trace function (whose specifi= cation and features are not part of this use case) is required, if the actu= al data plane of a router should be checked against its control plane.]", d= oes not looks like a benefit to me. Could you please highlight which are the specific benefits? --- "MPLS path trace function (whose specification and features are not part of this use case) is required, if the actual data plane of a router should be checked against its control plane." That sentence is 2 years old. Since then, has the MPLS WG progressed on thi= s? If so, could you please indicate the related draft. If not, why? And is this related to a further paragraph: " Documents discussing SR OAM requirements and possible solutions to allow SR usage as described by this document have been submitted already, see [I-D.ietf-spring-sr-oam-requirement] and [I-D.ietf-mpls-spring-lsp-ping]." If so, both could probably be merged. Any may be "already" is not appropriate for an RFC. --- >From an editorial standpoint, I feel that the text mixes: - the monitoring part, which is expected to be forwarded in the dataplane j= ust like users packets. - the trace/OAM features, which requires specific features on transit nodes= , hence are not forwarded in the dataplane like users packets. May be those 2 functions could be better distinguished in the text. --- "By utilising the ECMP related tool set offered e.g. by RFC 4379 [RFC4379],= a segment based routing LSP monitoring system may: o easily detect ECMP functionality and properties of paths at data leve= l." It's not clear to me what is meant by "properties" nor "at data level". Regarding detecting ECMP functionality, it could be detected with SR IGP ex= tensions, both for layer 3 ECMP (adj_SID) and layer 2 ECMP (draft-ietf-isi= s-l2bundles). Or may be you mean load-balancing behavior over ECMP links/path. But this i= s not what is written. --- "limit the MPLS label stack of an OAM packet to a minmum of 3 labels." Do you mean :s/minmum/maximum Why is this important? - If this is a hard limitation on the SRMS, then the probing packets would = also need to have a max of 3 labels. Which is typically not achievable. - Why would the SRMS have such a limitation for a pure software based featu= re? --- "It doesn't have to support any specialised protocol stack," What do you mean by this? It does need to support the MPLS protocol stack, probably the IP protocol s= tack, the IGP protocol stack in order to learn the topology/labels, the LSP= Ping protocol stack if OAM test are required.... --- "The MPLS monitoring servers are the single entities pushing monitoring pac= ket label stacks." may be :s/single/only :s/pushing/sending and receiving --- "If the depth of label stacks to be pushed by a path monitoring system (PMS) are of concern for a domain, a dedicated server based path monitoring architecture allows limiting monitoring related label stack pushes to these servers." If the limitation is on the PMS, as already expressed I don't see why a pur= e software packet sender would be limited in term of the number of labels (= which are just bytes) sent. If the limitation is elsewhere, could you pleas= e elaborate. The second part of the sentence could be rephrased for an easier understand= ing. (it took me 3 readings to guess that the important part is running the= PMS on dedicated server. Although I'm even sure why using a software on a = server solves the problem compared to using a software on the routing engin= e of a router (which may also be x86). --- =A73 "It can send pure monitoring packets" What do you mean by "pure"? >From the next sentence, I'd guess that you mean "monitoring packets with an= y payload" --- "Segment Routing here is used as a means of adding label stacks and hence transport to standard MPLS OAM packets, which then detect correspondence of control and data plane of this (or any other addressed) path." Could probably be better rephrased. e.g. Segment Routing here is used as a mean of transporting probes or standard M= PLS OAM packets, along any path. When MPLS OAM packets are used, consist= ency between control and data plane may be checked. --- "if the PMS is an IP host not connected to the MPLS domain, the PMS can send its probe with the list of SIDs/Labels onto a suitable tunnel providing an MPLS access to a router which is part of the monitored MPLS domain." Probably some text should be added to cover this point. (e.g. the tunnel MU= ST be secured and provide authentication of the sender and cryptographic si= gnature. Also this has security implication as MPLS VPNs are based on the inability = of the sender to send MPLS packet, while this option open this door. This s= hould be discussed in the security consideration section. ---- =A74.1 "To be able to work with the smallest possible SR label stack, first a suit= able MPLS OAM method is used to detect the ECMP routed path between LER i t= o LER j which is to be monitored " This is not very clear to me. Could this be rephrased? e.g. What to do mean= by "MPLS OAM method?" Is this MPLS OAM API (e.g. LSP ping)? Is this an alg= orithm to define the path? (but the end of the sentence seems to indicate t= hat the path is given as input "which is to be monitored") is "detect" the = best term? Also, this really the first sentence of the section. Could you first introd= uce the global picture and the goal, rather than starting with an optimisat= ion "To be able to work with the smallest possible SR label stack" --- "The packet will only reliably use the monitored path, if the label and address information used in combination with the MPLS OAM method of choice is identical to that of the monitoring packet." Could this be rephrased to improve clarity? ---- "The path PMS to LER i must be available." "The path LER j to PMS must be a= vailable." Given that the goal is to monitor paths which are assumed to be available, = if you detect a packet loss, how do you know which segment has an error? In= deed, packet loss could happen on this PMS to LERi path, while you think th= at you are measuring the path LER i to LER j. --- "This path must be detectable" What does this mean? --- "If ECMP is deployed, it may be desired to measure along both possible path= s which a packet may use between LER i and LER j." - ECMP may be more than both. - If you don't want to follow an ECMP path, why are you sending packet alon= g an ECMP path? SR allows enforcing a single path among multiple ECMPs. ---- "Further changes in ECMP functionality at LER i will impact results." Can you elaborate on this? Some LSR dynamically change their load-balancing= behavior in order to try to equally spread the load on all ECMP paths. Is = this behavior an issue? (i.e. are PMS and dynamic load-balancing adaptation= mutually incompatible?) Also if you want to monitor the (customer) ECMP path, would it be good to d= etect any change in this path, including a change trigger by such dynamic l= oad-balancing adaptation? And if you don't want to monitor the ECMP path, may be you should only moni= tor individual path. ---- " Determining a path to be executed prior to a measurement may also be done by setting up a label stack including all Node SIDs along that path (if LSR1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities." Adding all node SID do not remove ECMP functionnality. e.g. there could = be multiple links between LSR1 and LER i. --- "Monitoring an MPLS domain by a PMS based on SR offers the option of monitoring complete MPLS domains with little effort and very excellent scalability." Why is the scalability excellent? It looks to me that some links near the P= MS will be "heavily" used to test all paths. "little effort" is not very specific. IMHO a key benefit is the ability to = monitor all network paths by deploying a single PMS, while some others tech= niques requires the deployment of many probes. --- "The PMS does not require access to LSR/LER management interfaces " The choice of the term "interfaces" seems debatble to me as it could be mis= read as physical interface being monitored. As the goal of this document is= to monitor path and interfaces, I'd rather use "interface" only to refer t= o physical interface. --- =A74.2 Same comment: if the PMS detects loss of probe packets, it does not know wh= ether the loss happens on the monitored bundle, or the path from the PMS to= R2 or the path from R1 to the PMS. So how do you compute/measure the characteristics of the sub-path (here the= bundle) that you want to monitor? --- =A74.3 "In the previous example, a uni-directional fault on the middle link in direction of R2 to R1 would be localized by sending the following two probes with respective segment lists: o 72, 662, 992, 664 o 72, 663, 992, 664" "The first probe would fail while the second would succeed." I would have said the opposite as 663 maps to the middle link which is assu= med to be faulty. The formulation of the text is debatable as you are using the a priori know= nledge of the failure in order to define the probes which needs to be sent. More generally, as you are sending packets over a path longer than the one = to be tested, what you need is to also monitor those extra sub-path in orde= r to be able to check whether the failure is indeed on the sub-path that yo= u want to test, rather than the paths from the PMS to the first node on the= tested path, or the path from the last node on the tested path to the PMS. --- =A76 "Next: LDP or RSVP-TE label identifying the path to LER j at LER i. if LER j is the ingress of the RSVP-TE LSP, LER j does not have a label ide= ntifying this LSP. Eventually, SR may allocate a binding SID to this RSVP-T= E LSP. if LER j is a transit LSR of the RSVP-TE LSP, how does the PMS learn this l= abels, which a priori is only know from LER j and its upstream LSR. --- =A77 " MPLS SR topology awareness should allow the SID to monitor liveliness of most types of SIDs (this may not be recommendable if a SID identifies an inter domain interface)" Why would it not be recommendable to monitor an inter domain SID/interface? --- "To match control plane information with data plane information, MPLS OAM functions as defined for example by RFC 4379 [RFC4379] should be enhanced to allow collection of data relevant to check all relevant types of Segment IDs." Is there a document working on this? (e.g. draft-ietf-mpls-spring-lsp-ping = ?) If so, it could be referenced. --- =A78 "While the PMS based use cases explained in Section 3 " I think uses-cases are explained in section 4. --- =A76 "An implementation report on a PMS operating in an LDP domain is given in [= I-D.leipnitz-spring-pms-implementation-report]" This document is more than an implementation. IMHO it would deserve a short= text introducing its scope and result. e.g. "[I-D.leipnitz-spring-pms-implementation-report] present a PMS implementati= on report and compare delays measured with one PMS to the results of three = IPPM standard conformant Measurement Agents, using the IPPM methodology as = defined in [RFC6576]. The results show that the PMS measurements equal those captured by an IPPM conformant measurement system. The ADK test is successful by comparing the measurement values of the round-trip delays for packets with a size of 64 bytes." (but I'm not an IPPM expert, so authors should be able to provide a better = text) =3D=3D=3D=3D=3D Nits "IGP LSA" LSA is not defined nor expanded on first use. Plus it is protocol specific (OSPF). Could you cover both OSPF and IS-IS or= use a term which is not protocol specific? Especially since a priori you m= ean LSDB analysis, rather than LSA. --- :s/minmum/minimum --- OLD: used as a means of adding label stacks and hence transport to standard= MPLS OAM packets NEW: used as a mean of adding label stacks and hence transport standard MPL= S OAM packets to any node ___________________________________________________________________________= ______________________________________________ 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_eed31f8f266b467d93867be85c732950HE101653emea1cdstintern_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Brun= o,

&n= bsp;

before = reading - thanks for sheperding and thanks for your review.

&n= bsp;

Hope, y= ou had a good start into 2017,

&n= bsp;

Ruedige= r

&n= bsp;

Von: bruno.dec= raene@orange.com [mailto:bruno.decraene@orange.com]
Gesendet: Dienstag, 17. Januar 2017 17:35
An: draft-ietf-spring-oam-usecase@ietf.org
Cc: spring@ietf.org; spring-chairs@ietf.org
Betreff: draft-ietf-spring-oam-usecase - shepherd review<= /span>

 

Hi authors,

 

As the document shepherd, I hav= e reviewed draft-ietf-spring-oam-usecase-04.

Please find some comments below= .

 

Best regards,=

Bruno

---

 

=3D=3D=3D=3D=3D Major comment

Multiple sections or text of th= e document seems to mix continuity check and connectivity verification. I t= hink the document would be clearer if both points were more structured. e.g= . introducing each, then explaining their interactions, then detailing each one independently, possibly in ind= ependent sub-section.

 

=3D=3D=3D=3D=3D Minor comments<= o:p>

=A72

"enabling MPLS topology de= tection based on IGP signaled segments as specified at [I-D.ietf-isis-segme= nt-routing-extensions] and

   [I-D.ietf-ospf-seg= ment-routing-extensions]."

You could probably add &nb= sp; draft-ietf-idr-bgp-ls-segment-routing-ext, as an external server is les= s likely to be part of the IGP.

 

----

"As compared to LDP, Segme= nt Routing is expected to simplify the system by enabling MPLS topology det= ection based on IGP signaled segments"

I find the term "MPLS topo= logy" loosely defined. As I read it, it could encompass:

- the network topology, which c= an be learnt by listening to the IGP, regardless of the use of LDP or Segme= nt Routing

- MPLS signaling topology. With= segment routing, it can be learnt by listening to IGP. For LDP, it would r= equire looking at the LDP configuration or LDP status.

- MPLS signaled labels. With se= gment routing, it can be learnt by listening to IGP. For LDP, it would requ= ire one T-LDP session per node.

 

Could you please elaborate on w= hat is exactly meant with "MPLS topology"?

 

---

One paragraph is about the use = of SRMS in LDP network. "The system applies to monitoring of LDP LSP's= ...."

Another paragraph is about the = use of SRMS in pre-segment routing networks. "The MPLS path monitoring= system described by this document can be realised with pre-Segment Routing= (SR) based technology."

 

It's not crystal clear to mean = what you mean by "pre-Segment Routing (SR) based technology." I c= ould read "LDP", in which case, both paragraph are about the same= subject. In which case, an editorial update would be useful to merge those two paragraphs, as they are related to the same case. (or a= t least very related)

 

---

"The system offers several= benefits for network monitoring."

I would expect those benefits t= o be spelled out in the document. The sentence is indeed followed by a set = of sentences, but it's not clear to me whether those sentences details thos= e benefits or not. The first two sentences looks like benefits. The third one ["MPLS path trace function (whose = specification and features are not part of this use case) is required, if t= he actual data plane of a router should be checked against its control plan= e.]", does not looks like a benefit to me.

Could you please highlight whic= h are the specific benefits?

 

---

"MPLS path trace function = (whose specification and features

   are not part of th= is use case) is required, if the actual data plane

   of a router should= be checked against its control plane."

 

That sentence is 2 years old. S= ince then, has the MPLS WG progressed on this? If so, could you please indi= cate the related draft. If not, why?

 

And is this related to a furthe= r paragraph:

"   Documents di= scussing SR OAM requirements and possible solutions to

   allow SR usage as = described by this document have been submitted

   already, see [I-D.= ietf-spring-sr-oam-requirement] and

   [I-D.ietf-mpls-spr= ing-lsp-ping]."

   =

If so, both could probably be m= erged.

Any may be "already" = is not appropriate for an RFC.

 

---

From an editorial standpoint, I= feel that the text mixes:

- the monitoring part, which is= expected to be forwarded in the dataplane just like users packets.

- the trace/OAM features, which= requires specific features on transit nodes, hence are not forwarded in th= e dataplane like users packets.

 

May be those 2 functions could = be better distinguished in the text.

 

---

"By utilising the ECMP rel= ated tool set offered e.g. by RFC 4379 [RFC4379], a segment based routing L= SP monitoring system may:

   o  easily det= ect ECMP functionality and properties of paths at data level."

It's not clear to me what is me= ant by "properties"  nor "at data level".

Regarding detecting ECMP functi= onality, it could be detected with SR IGP extensions, both for layer 3 ECMP= (adj_SID)  and layer 2 ECMP (draft-ietf-isis-l2bundles).

Or may be you mean load-balanci= ng behavior over ECMP links/path. But this is not what is written.

 

---

"limit the MPLS label stac= k of an OAM packet to a minmum of 3 labels."

Do you mean :s/minmum/maximum <= o:p>

 

Why is this important?

- If this is a hard limitation = on the SRMS, then the probing packets would also need to have a max of 3 la= bels. Which is typically not achievable.

- Why would the SRMS have such = a limitation for a pure software based feature?

 

---

"It doesn't have to suppor= t any specialised protocol stack,"

What do you mean by this? =

It does need to support the MPL= S protocol stack, probably the IP protocol stack, the IGP protocol stack in= order to learn the topology/labels, the LSP Ping protocol stack if OAM tes= t are required....

 

---

"The MPLS monitoring serve= rs are the single entities pushing monitoring packet label stacks."

may be

:s/single/only

:s/pushing/sending and receivin= g

 

---

"If the depth

   of label stacks to= be pushed by a path monitoring system (PMS) are of

   concern for a doma= in, a dedicated server based path monitoring

   architecture allow= s limiting monitoring related label stack pushes to

   these servers.&quo= t;

   =

If the limitation is on the PMS= , as already expressed I don't see why a pure software packet sender would = be limited in term of the number of labels (which are just bytes) sent. If = the limitation is elsewhere, could you please elaborate.

The second part of the sentence= could be rephrased for an easier understanding. (it took me 3 readings to = guess that the important part is running the PMS on dedicated server. Altho= ugh I'm even sure why using a software on a server solves the problem compared to using a software on the routing= engine of a router (which may also be x86).

 

---

=A73

"It can send pure monitori= ng packets"

What do you mean by "pure&= quot;?

From the next sentence, I'd gue= ss that you mean "monitoring packets with any payload"=

---

"Segment=

   Routing here is us= ed as a means of adding label stacks and hence

   transport to stand= ard MPLS OAM packets, which then detect

   correspondence of = control and data plane of this (or any other

   addressed) path.&q= uot;

   =

Could probably be better rephra= sed. e.g.   

 

Segment Routing here is used as= a mean of transporting probes or standard MPLS OAM packets, along any path= . When MPLS OAM packets are used,    consistency between con= trol and data plane may be checked.

 

---

"if the PMS is an IP host = not connected to the MPLS domain,

   the PMS can send i= ts probe with the list of SIDs/Labels onto a

   suitable tunnel pr= oviding an MPLS access to a router which is part of

   the monitored MPLS= domain."

 

Probably some text should be ad= ded to cover this point. (e.g. the tunnel MUST be secured and provide authe= ntication of the sender and cryptographic signature.

Also this has security implicat= ion as MPLS VPNs are based on the inability of the sender to send MPLS pack= et, while this option open this door. This should be discussed in the secur= ity consideration section.

 

----

=A74.1

 

"To be able to work with t= he smallest possible SR label stack, first a suitable MPLS OAM method is us= ed to detect the ECMP routed path between LER i to LER j which is to be mon= itored "

This is not very clear to me. C= ould this be rephrased? e.g. What to do mean by "MPLS OAM method?"= ; Is this MPLS OAM API (e.g. LSP ping)? Is this an algorithm to define the = path? (but the end of the sentence seems to indicate that the path is given as input "which is to be monitored") is &= quot;detect" the best term?

 

Also, this really the first sen= tence of the section. Could you first introduce the global picture and the = goal, rather than starting with an optimisation "To be able to work wi= th the smallest possible SR label stack"

---

"The packet will

   only reliably use = the monitored path, if the label and address

   information used i= n combination with the MPLS OAM method of choice is

   identical to that = of the monitoring packet."

 

   Could this be reph= rased to improve clarity?  

----  

"The path PMS to LER i mus= t be available." "The path LER j to PMS must be available."

Given that the goal is to monit= or paths which are assumed to be available, if you detect a packet loss, ho= w do you know which segment has an error? Indeed, packet loss could happen = on this PMS to LERi path, while you think that you are measuring the path LER i to LER j.

---

"This path must be detecta= ble"

What does this mean?=

 

---

"If ECMP is deployed, it m= ay be desired to measure along both possible paths which a packet may use b= etween LER i and LER j."

- ECMP may be more than both.

- If you don't want to follow a= n ECMP path, why are you sending packet along an ECMP path? SR allows enfor= cing a single path among multiple ECMPs.

 

----

"Further changes in ECMP f= unctionality at LER i will impact results."

Can you elaborate on this? Some= LSR dynamically change their load-balancing behavior in order to try to eq= ually spread the load on all ECMP paths. Is this behavior an issue? (i.e. a= re PMS and dynamic load-balancing adaptation mutually incompatible?)

Also if you want to monitor the= (customer) ECMP path, would it be good to detect any change in this path, = including a change trigger by such dynamic load-balancing adaptation?<= /o:p>

And if you don't want to monito= r the ECMP path, may be you should only monitor individual path.=

----

"   Determining = a path to be executed prior to a measurement may also be<= /p>

   done by setting up= a label stack including all Node SIDs along that

   path (if LSR1 has = Node SID 40 in the example and it should be passed

   between LER i and = LER j, the label stack is 20 - 40 - 30 - 10).  The

   advantage of this = method is, that it does not involve MPLS OAM

   functionality and = it is independent of ECMP functionalities."

 

   Adding all node SI= D do not remove ECMP functionnality. e.g. there could be multiple links bet= ween LSR1 and LER i.

 

  ---

  "Monitoring an MPLS= domain by a PMS based on SR offers the option of

   monitoring complet= e MPLS domains with little effort and very

   excellent scalabil= ity."

Why is the scalability excellen= t? It looks to me that some links near the PMS will be "heavily" = used to test all paths.

"little effort" is no= t very specific. IMHO a key benefit is the ability to monitor all network p= aths by deploying a single PMS, while some others techniques requires the d= eployment of many probes.

 

---

"The PMS does not require = access to LSR/LER management interfaces "

The choice of the term "in= terfaces" seems debatble to me as it could be misread as physical inte= rface being monitored. As the goal of this document is to monitor path and = interfaces, I'd rather use "interface" only to refer to physical interface.

 

---

=A74.2

Same comment: if the PMS detect= s loss of probe packets, it does not know whether the loss happens on the m= onitored bundle, or the path from the PMS to R2 or the path from R1 to the = PMS.

So how do you compute/measure t= he characteristics of the sub-path (here the bundle) that you want to monit= or?

 

---

=A74.3

   "In the = previous example, a uni-directional fault on the middle link

   in direction of R2= to R1 would be localized by sending the following

   two probes with re= spective segment lists:

   o  72, 662, 9= 92, 664

   o  72, 663, 9= 92, 664"

   =

 

"The first probe would fai= l while the second would succeed."

I would have said the opposite = as 663 maps to the middle link which is assumed to be faulty.

 

The formulation of the text is = debatable as you are using the a priori knownledge of the failure in order = to define the probes which needs to be sent.

More generally, as you are send= ing packets over a path longer than the one to be tested, what you need is = to also monitor those extra sub-path in order to be able to check whether t= he failure is indeed on the sub-path that you want to test, rather than the paths from the PMS to the first nod= e on the tested path, or the path from the last node on the tested path to = the PMS.

 

---

=A76

"Next: LDP or RSVP-TE labe= l identifying the path to LER j at LER i.

 

if LER j is the ingress of the = RSVP-TE LSP, LER j does not have a label identifying this LSP. Eventually, = SR may allocate a binding SID to this RSVP-TE LSP.

if LER j is a transit LSR of th= e RSVP-TE LSP, how does the PMS learn this labels, which a priori is only k= now from LER j and its upstream LSR.

 

---

=A77

"   MPLS SR topo= logy awareness should allow the SID to monitor liveliness=

   of most types of S= IDs (this may not be recommendable if a SID

   identifies an inte= r domain interface)"

   =

Why would it not be recommendab= le to monitor an inter domain SID/interface?

---

      = "To match control plane information with data plane information, MPLS<= o:p>

   OAM functions as d= efined for example by RFC 4379 [RFC4379] should be

   enhanced to allow = collection of data relevant to check all relevant

   types of Segment I= Ds."

Is there a document working on = this? (e.g. draft-ietf-mpls-spring-lsp-ping ?) If so, it could be reference= d.

   =

---

=A78

"While the PMS based use c= ases explained in Section 3 "

I think uses-cases are explaine= d in section 4.

---

=A76

"An implementation report = on a PMS operating in an LDP domain is given in [I-D.leipnitz-spring-pms-im= plementation-report]"

This document is more than an i= mplementation. IMHO it would deserve a short text introducing its scope and= result. e.g.

"[I-D.leipnitz-spring-pms-= implementation-report] present a PMS implementation report and compare dela= ys measured with one PMS to the results of three IPPM standard conformant M= easurement Agents, using the IPPM methodology as defined in [RFC6576].

The results show that the PMS m= easurements equal those captured by

   an IPPM conformant= measurement system.  The ADK test is successful by<= /p>

   comparing the meas= urement values of the round-trip delays for packets

   with a size of 64 = bytes."

   =

(but I'm not an IPPM expert, so= authors should be able to provide a better text)  

 

=3D=3D=3D=3D=3D Nits=

"IGP LSA"<= /span>

LSA is not defined nor expanded= on first use.

Plus it is protocol specific (O= SPF). Could you cover both OSPF and IS-IS or use a term which is not protoc= ol specific? Especially since a priori you mean LSDB analysis, rather than = LSA.

---

:s/minmum/minimum

---

OLD: used as a means of adding = label stacks and hence transport to standard MPLS OAM packets

NEW: used as a mean of adding l= abel stacks and hence transport standard MPLS OAM packets to any node<= /o:p>

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_eed31f8f266b467d93867be85c732950HE101653emea1cdstintern_-- From nobody Thu Jan 26 04:41:54 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 6BCAD129570; Thu, 26 Jan 2017 04:41:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148543451340.16570.7598628331536264802.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2017 04:41:53 -0800 Archived-At: Cc: aretana@cisco.com, spring@ietf.org, spring-chairs@ietf.org, bruno.decraene@orange.com Subject: [spring] spring - New Meeting Session Request for IETF 98 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 12:41:53 -0000 A new meeting session request has just been submitted by Bruno Decraene, a Chair of the spring working group. --------------------------------------------------------- Working Group Name: Source Packet Routing in Networking Area Name: Routing Area Session Requester: Bruno Decraene Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: bess isis ospf Second Priority: 6man mpls rtgwg idr pce Third Priority: sfc teas ccamp Special Requests: --------------------------------------------------------- From nobody Fri Jan 27 03:05: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 51F9D1294A4; Fri, 27 Jan 2017 03:05:17 -0800 (PST) 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 3tNtDlxeCtdY; Fri, 27 Jan 2017 03:05:16 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0102.outbound.protection.outlook.com [104.47.0.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591F21294A2; Fri, 27 Jan 2017 03:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wdFpd09riohvRw/Y6fUmQSIDh+tiLEXqpLzB60QQ3j0=; b=VdeP2PhpIqtZf1PX3d26fXK5PKdYGI1LeiMOSqTA4NKJH3OSCH8qw7VTUJbVSSV1hYhRpPGRCa8zTbaryrjVvo6KpPB36V2UI/rFI+fQG1wlstwxeM/LgmIJujYvFBqYbelyEI9syinkYjKklF5snvYjJj4mo12y+Q9Sg57d8Dg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [192.168.1.5] (86.247.3.219) by DB6PR0701MB2469.eurprd07.prod.outlook.com (10.168.75.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Fri, 27 Jan 2017 11:05:09 +0000 From: Martin Vigoureux To: Message-ID: Date: Fri, 27 Jan 2017 12:05:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [86.247.3.219] X-ClientProxiedBy: HE1PR0501CA0005.eurprd05.prod.outlook.com (10.168.27.143) To DB6PR0701MB2469.eurprd07.prod.outlook.com (10.168.75.150) X-MS-Office365-Filtering-Correlation-Id: 3cbe2fa6-96b8-4371-7433-08d446a45bdd X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401076); SRVR:DB6PR0701MB2469; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 3:d3ja0M0LPbbZT6AiAEb8TljH5s0trJcu95KinHM6Zi9SpUjv3fjL8VvmVuV38K0QQEBDm9kyHfVScaNjQPyfSUHqt/nE7/XxWeeb+4fngjyfW5cjbrou8umSpcGnF3SuLjbHD4TKJ0pAfaQL0nbNqx3XufCXboFK77tKPSyOgwGdqC8Dfd1e1+Z90jQD7cj9Rmm4iO3vVLRTCazAvPMenwVXXxgI3Rc2PmBWbh0MSkdtK29BWnFN+yRM6B8zlT7R7/Y9sdXWjsUWYIewDNaRAVPO+FA6+njdjeZiPWTV1vM=; 25:fIoy9uHOVrSdVaY98yWiDh5snK00WHuEwuiSXIx8GHDwgWogwuUSA/33ZdHjQfVfk50tbhveJpEBspRcPCwECz2vJd/YUYUQXBzqxyIY0+bfBCnOzHbDplWRt81K6SwgChTcFUCkC/E5vbUN2ssCVTt2Ov43tphSWR3MeHKL+J7z5nrqvDeUjfFHsi+nwAeUBRcxJWLeYsblcPXAVynqz0VV/WMJQ0qg1gVhGyiV3LiFJ84GPBpoJFR3y89JirANgObJ/4glLPxgQAwraQKqdV4/+3TVcu0C9Wn+AaHobVJWFBHmpi1+l23tLPAhUgbxecEbEFNn+c4zTpyGJSjbAQZ+RnBiS/+JFHC3sgXmrT/X1nMIjXo+YX7Shzb0Hq0EkC0QQDlFJcrNK1XuD8j+4N26Xk2TVJ8TCACHAKLalJeiseNVif/9jC1Q2dvh79+7wJzVwcehg4gAVtexMA30+A== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 31:ighbbXuuBgGMXfJIhWORTIJ+gloRU27950KyB/3UwlqXYASg4vAfRDWCJ9LayfM8lJpkil5Je2h5GPHvJq0UpqFAAYN+tC0FOAHsjfuL0M/ySH8bwRIgQTIxx5ceJAbd611IlnfY6Yza3cmC3JMlnz/7Yqm58tMhmeNGsSgDPcGOYcj1YEZGCNzKd9O+HomBhYpIyEQxG1luXneFUv9vL/3nhK6WalHp6btC7U609har7Tt7mSDCYnHCc9xTEAsvMEo4EoV1sFp84cDEjtzE08hoVb0vEQ+tEHL2aioVpaQ=; 20:zvIfI/iSJ1wIKLab5GzccDeoTVKEdBMV/QItvq7FmKI9syD0537bYN9DveBJ99AWe7ZGHg/ZPFRrxaumWehd6XE5fVjYl/RaVTYs1EPK+L3bAa58cTmtqTC52SYoRaGbWqttdNtQyAMjs1l5n5RGIXdASQNVab73yl9slw0w20p8oIcH5vrCtf1/XGpDNKzQTfljfONMAZH5Z7Lmq1u2XgJzNpKO7gA/w8Zf7/cZj7DAY0hz/3XleSashs/faFplRqs0KuhsuWQVeiE+hZDuI7O/L3w2vapo8tg/eW6qUPIWF8c/F2bkIHMM0+z+NHSilFAbxS0oxkEbqyBmH17IslrwwZ+2SMMd0eoLhRbakAH69fRMNCRJTqr4nyv2sCeVE/ocYr+5p4wpqp/55GI/ZXK0uUsYuZJSJmFH3GH6KzuaO28vV6Vnr8frtFpHHM01qPZ6TJoCPqFPv00OLR8rL29wYMLD59TKrzfqJYarV1GsitPVy81Z0zoHaeIBM9ee X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:DB6PR0701MB2469; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2469; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 4:Z3MS8+Dojzgm3KmNwtFO1wefRX+0nxw7JqDEjlUx18TuijJMF1G1m/sJnnLVdkRaFxb9ieS6wgBQshVrqKhRmCas7Svm7ZGuX78uLoSgYohSj/vSeweihJ02m3pM68MdAwv2ibHu5agJ+gkOA3o8tb173E8+YL2QuM5UGSuX1nxDXAppruu16NDf5KwbpTpSogkIGfLnSuiNK9IjYcdnKLAXNtV0FXojvu8VNm/0NsmtduUwPgmTNrAnxBfdajuwbWtJXqAjMrD9nKEXeAL41ZGjvuCsHUWPqgOMtQjYNeon2IDqS61OvPykK2l4FQ4dSawXaVv/JNqI2DqODgfIw0l5AOz8ndxGPGxnSZuEv9oCsV21i5xJl+Y/554B8lrcld7tzbInj4iIF/3VHiKvBRGxMyI82IpV62YxUJ/sg5rmGNYh+cRKd0jdlbcoEemT/ydXCJ7wUTUVzzfI8Oey1zelMjAbTpulyulMvIolNMOSJRDO24hSXzmRrz68nYxLhGwkThGRuB9g7c4tTnjFuOyVDDnNyc4xBu6Fj/MVCFyxZfpkpCRx8wRBGIOXftW+7yNWBEcVR9WGsDKWVNX/C8YraEMCEB6+tNwWwwXUuY3sx22lmfZMQKaN/Ip16Qru0pB6ExQ19mABHaSRqMujUA== X-Forefront-PRVS: 0200DDA8BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39840400002)(39860400002)(39410400002)(39850400002)(39450400003)(189002)(199003)(4326007)(305945005)(2906002)(2870700001)(7736002)(450100001)(68736007)(65826007)(50466002)(110136003)(3846002)(6116002)(64126003)(5660300001)(81156014)(81166006)(53936002)(83506001)(4001350100001)(97736004)(8676002)(92566002)(101416001)(42186005)(31686004)(6916009)(6666003)(6306002)(54356999)(189998001)(50986999)(106356001)(105586002)(6486002)(66066001)(65806001)(38730400001)(77096006)(33646002)(47776003)(117156001)(230783001)(90366009)(65956001)(23746002)(36756003)(86362001)(31696002)(25786008)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2469; H:[192.168.1.5]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB6PR0701MB2469; 23:ebZnT+k5LOivF6QO0+8pG0lfPVOwubwqYw5?= =?Windows-1252?Q?NMeVgzkQTQHQ51PUkQ0FxaDMl3wVO/sRR5C+Lv0XCSJiMygj5I4dZt+l?= =?Windows-1252?Q?E1Vt5kG+bwyOoxoPXU6MUUJlCUWkJ3BYgKs/T7pIxJewL1CqCYIv3EvS?= =?Windows-1252?Q?kHs30RYzFAqZ0BOpX0goZewEBptwqaTj3kEOOtRIoXPEv5mGVCSGE/ke?= =?Windows-1252?Q?3WPrA/RpAe6Dvx9qcwrKXdh++EtpOlm5rJ4CiCG5SNb9L5o351iDHdJf?= =?Windows-1252?Q?dbHEBwwW1jwUgDfOmbhrDDL4fNyvawCXoZKBlk5FotNYXFtJuC+tNwoZ?= =?Windows-1252?Q?Ks0+ZnRO8N6y6rKVrZyA5CDd7HjNkV0B7lhLpslNlQZTuIoa4PomZCHq?= =?Windows-1252?Q?luSjIgqZTgKo73efbPRMnUkaZ/L8+du5+P4UKVeAPbD74laM9SCstovj?= =?Windows-1252?Q?IxBVj4wsD0KFR86tpbUDclDPpoOmXf1tEhtISmMCFwR1/X4Q48Qez/be?= =?Windows-1252?Q?AALaVRtArB9ODYRECdKJZ260MiVyEmt5N1e0pSJnK/usS/SMcDJnzWsw?= =?Windows-1252?Q?Xrkfm8JY/9UFAjioeMj97oWp/O8XAx7TSTVm3LyP4E+Vd+Lqug+RXz4r?= =?Windows-1252?Q?RMLku7Vc/DzUMHA+VDYtSj2E9KCa0GysiPNZVR4Rx+yeeIKZUX6h2Nyp?= =?Windows-1252?Q?CDNSnYTRVSE8SSvURlnWdN1DKbjgk+rF/yTd4qVEvljSITRbc6jYka23?= =?Windows-1252?Q?yLkrnI7yqUbgH276COv9gamYXcVJaC66aPhCwpc1z9AS9ZKdpZi43hNu?= =?Windows-1252?Q?PJL5YYgJk1MYtDjUcCBQkiln8wFuxoBum2pmaxhHquIu8hVF2QE4SYjp?= =?Windows-1252?Q?AQcySZBGKJo31wFJ0F5dQ8fPhIiA7t0xX9vZGPDCrmPmJ/L/0xjascDs?= =?Windows-1252?Q?Itz5mbvLuRf/+LVcEYC0LOMWmn1rG0xgRhmV153PlUgMArKmWFMeJojM?= =?Windows-1252?Q?8Zu8tjtMnjIpJdYDDJevn+5QRmEETaZejgID06JBgWP30qaEHJ4KlUrP?= =?Windows-1252?Q?HzdH6kTHrpJPmJGSAZHBTSFLrv6IdHhEuSjc7B96fwTtEanCwOSnErj1?= =?Windows-1252?Q?tvxR/O0Q3QspmLkmkDsXDaWDjwRy5soP88UIlf7J/W0+m2dg6gePyznT?= =?Windows-1252?Q?p9rSJohrRIwwXh2ozb5YKIb8TRnmZvr4HCNyjgVoR6O+/O6RWGVZG/gU?= =?Windows-1252?Q?xWWEQZDeAytgH4dhPc6l/Korn5oF0ywMlAh2EAkr+J+YcrGNWltQ6HrV?= =?Windows-1252?Q?ScEbqe+MEOIhxHdp/9gJcXneDgByO71wkYrgzV4ugDoUEaqATgfae4I1?= =?Windows-1252?Q?2BFKUcboD+KRPNYOHw6iblTAqciHDKY6aspDhhjOzctrLxgbg2CRaIaD?= =?Windows-1252?Q?Gkzqd2ykWpJrGWO9jXVTOxwWG3Qj2F2QzNvoXwoSJNSa0Pz+DDnYgKGu?= =?Windows-1252?Q?LvaDDXcrxRJHnuIMSSEQnHncsLGfPiuXpcCuBUh5EkjvgncTpuUkl12+?= =?Windows-1252?Q?kYb64Gg2y8rGi7+FWoWrFiSAIGYLoYe14JH7A?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 6:+muFPJmeNXpgU3dYclI+8o17ETbFgFsJQVVoapG+RsG6U4HF06uR4ASWt8otCh6ZZgBaRkbvDkcvrVYYdfm/nrkIoKTetDQNbsPVTQaZ8zgRr7KRYKS3VZgcvnE0oSOQxh0njaE7ACRErEaElYWDn95bE81q+pKUKeh/LiS/3Y9XvfLuGpQJssK0AT7nq0OeM5+gHTwf9jZILIKWvKsS/P9NY62Xbaye+UCOJdSxhjWwbJLxLEjlQv5+k8XAtagct8fff8EqXyCnhduSUawi3uPUanLWU9mUMJ7K1I99h++Um/dKh6EPEDP5GVTs5YYroi2Qy/n8Xb8qIbQCE1CcYlvyYKtZSF8nlMsAsTq5uwHUak78Z93j5P+r5DcEjnK9eJsGpOrhnb1aqbNNb17ZzOP6Cb54VPk0RG29Y3rN0ohNw7BXRnMTPZkJ/Oe1xy/WBWJ0tT2Wu1N7BXJIPGjGkA==; 5:iS+orqNY3ve9kSqOwAQgOhLOQo7//w7Gv/kj6KtvruwbWsPkNBGFG07Wmtwswh2smMMnR+XiwGkpbMptdzCcCrZvKA2cBEl6OpPuJDq9kwkVX8w0AMwOX+ADxcjVG0gty3PwP74GxronWLKalm1V6Q==; 24:bWcQ9g6DdmrY7kVOqNe7Fp4AX9TNF2Vy7m+JL6o5THd7eyl0McmFZx8RVX7nFWc53JrcC4wdLbm+zezGB6p9hY+s3TjdTPjSWhe9zTQ2AC4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 7:chAoG9mSbWpV4BigScfs7taoO934ELbytxyWwDpD8zRVrylRnoNoRaRoKVdAsfC0ZMx7aGxm7jWBmtyNf8GSINEkSuGc8mKTnn2NVRVneyTRTJlkqbKzYc0YI3O5wdfL8R0axdlzKk0P83QA3OhChXFA6YB+ADXppUj0WKF8aTEn52sCHj2rkPVnPM+rVTpdH4noLPf9bthWLwVLLfnTVYJIT+DvnxafPQjcBupKV27pYZLwesN7rMAm9rnK+TlhIsteu6q2SvRgbKDTDgixSdOVzqp0nqo2H7Sj2/3aPLjPI3PN84MQwEvbos0Gz7aGPZGxTeIJ53NjNWCZ5x018Z3q0lprPOakgSscQyNenaqK4HU2KhzLChvB8kIKJ66QkraTjm7hnR/TTRoUIG1maFQWFWxNiffnIBPTo6sWX79HeBN5v0ARx/Tl1o9E6ZF+Z5Bz1zDbZGckaf7+IQP5PA== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2017 11:05:09.2230 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2469 Archived-At: Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 11:05:17 -0000 Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-mpls-06 [1]. ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *12th of February*. 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. ¤ We have already polled for IPR knowledge on this document and all Authors have replied. IPR exists against this document and has been disclosed [2]. Thank you M&B --- [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls From nobody Fri Jan 27 05:00: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 03ED312952B; Fri, 27 Jan 2017 05:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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=-3.199, 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 5A5zsxp01Whe; Fri, 27 Jan 2017 05:00:17 -0800 (PST) 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 835D7129519; Fri, 27 Jan 2017 05:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1638; q=dns/txt; s=iport; t=1485522017; x=1486731617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XVkPN3YAjtEyWl4y8Lm5irYL3qabklUmtDFAz5Obwmk=; b=BWV4NZVZTh94jpzPZvLWJfUESzFDnTXlJ39lg1bXNcQbhv7PsMuviwt0 uZz0lTY5ffeRLj0DrncVQS6gamCMSOJOzV9DLeEeRpG2CROyAlXzQ2JH/ VGNOPsVYHgv+7sPn7at2kTdIII7/ZWEmNqfo9H55txhjh93xX+PPkVYVF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQCxQ4tY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAR9hgQkHg06KCacvggwfDYUsSgIaggE/GAECAQEBAQE?= =?us-ascii?q?BAWIohGoCBAEBGxc6CxACAQgcKAICJQslAgQBDQWJYQ6PTZ1ICIIjimwBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYEHijODDIEPEQGDHoJjAQSbUQGGZosSgXmFEoN?= =?us-ascii?q?NhhySfQEfOHZVFTuGOXWGUoEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,295,1477958400"; d="scan'208";a="198866170" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jan 2017 13:00:16 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0RD0FBY024780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Jan 2017 13:00:16 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 27 Jan 2017 08:00:14 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 27 Jan 2017 08:00:15 -0500 From: "Acee Lindem (acee)" To: Martin Vigoureux , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Thread-Index: AQHSeI1ueYfdWJr+VUmqnlTriIp3hqFMSXiA Date: Fri, 27 Jan 2017 13:00:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.201] Content-Type: text/plain; charset="gb2312" Content-ID: <5A54D846BFC3E343817FDF7A85023FF0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 13:00:19 -0000 SGksIA0KDQpJIGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQgYW5kIHN1cHBvcnQgcHVibGljYXRpb24u DQoNClRoYW5rcywNCkFjZWUgDQoNCk9uIDEvMjcvMTcsIDY6MDUgQU0sICJzcHJpbmcgb24gYmVo YWxmIG9mIE1hcnRpbiBWaWdvdXJldXgiDQo8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIG1hcnRpbi52aWdvdXJldXhAbm9raWEuY29tPiB3cm90ZToNCg0KPkhlbGxvIFdvcmtp bmcgR3JvdXAsDQo+DQo+VGhpcyBlbWFpbCBzdGFydHMgYSAyLXdlZWsgV29ya2luZyBHcm91cCBM YXN0IENhbGwgb24NCj5kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0wNiBb MV0uDQo+DQo+oeggUGxlYXNlIHJlYWQgdGhlIGRvY3VtZW50IGlmIHlvdSBoYXZlbid0IHJlYWQg dGhlIG1vc3QgcmVjZW50DQo+dmVyc2lvbiB5ZXQsIGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8g dGhlIGxpc3QsIG5vIGxhdGVyIHRoYW4gdGhlDQo+KjEydGggb2YgRmVicnVhcnkqLg0KPk5vdGUg dGhhdCB0aGlzIGlzICpub3Qgb25seSogYSBjYWxsIGZvciBjb21tZW50cyBvbiB0aGUgZG9jdW1l bnQ7IGl0IGlzDQo+YWxzbyBhIGNhbGwgZm9yIHN1cHBvcnQgKG9yIG5vdCkgdG8gcHVibGlzaCB0 aGlzIGRvY3VtZW50IGFzIGEgUHJvcG9zZWQNCj5TdGFuZGFyZCBSRkMuDQo+DQo+oeggV2UgaGF2 ZSBhbHJlYWR5IHBvbGxlZCBmb3IgSVBSIGtub3dsZWRnZSBvbiB0aGlzIGRvY3VtZW50IGFuZCBh bGwNCj5BdXRob3JzIGhhdmUgcmVwbGllZC4NCj5JUFIgZXhpc3RzIGFnYWluc3QgdGhpcyBkb2N1 bWVudCBhbmQgaGFzIGJlZW4gZGlzY2xvc2VkIFsyXS4NCj4NCj5UaGFuayB5b3UNCj4NCj5NJkIN Cj4NCj4tLS0NCj5bMV0gDQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMvDQo+WzJdIA0KPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/c3VibWl0PWRyYWZ0JmlkPWRyYWZ0LWlldGYtc3By aW5nDQo+LXNlZ21lbnQtcm91dGluZy1tcGxzDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5zcHJpbmcgbWFpbGluZyBsaXN0DQo+c3ByaW5nQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Fri Jan 27 10:34:11 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 031C01296D8; Fri, 27 Jan 2017 10:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=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 Ydq0PXqJY6wm; Fri, 27 Jan 2017 10:34:07 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683631296DB; Fri, 27 Jan 2017 10:34:07 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id f144so19058268pfa.2; Fri, 27 Jan 2017 10:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=peaYhf4Sxfj6zsUzPoxGhzQfZPR3Ct7VW2q3ckuDxIo=; b=SD15e710KCD0D6s4CDJ8hRPzmUyxpydzVuGA4nGB7LS+Y8ObdjLjAWsupftcllLPtV 5Cb0NOvmRs5GaiJbT144fVOG74zUzzp/WTtdN+YqLllDw/kXS9WadFSrDMKjlqLDSOEa ONGFdjyCBatIYnlbRvoc/r57sbzaEWbgb9MfZ8xu7KshozCKdFJE8JdHhlA3LN7YRWO9 8nxScM4zQ3ybKgchw3MNJAoKRVUcGUQacFi23boVk5+wBFKeyGuT5d5AD/iuj8+pkaIh mv50uMZNzH4aU1wZdlIZJpFJU7Smi6GDVYGDk7hiOwLKVm0QTx+CXvtGM9ashdvmSwoH 7iCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=peaYhf4Sxfj6zsUzPoxGhzQfZPR3Ct7VW2q3ckuDxIo=; b=ophzJufIVQEKvN7rUHKACN14NY2Z/Dezgn2C9OysT1XsGtTNlCAv8nudLkL8vgQrX2 P5P9y8i4/5H5yFggFqGVy0UfosK1/L2lJoxqj3mUR81K0ej9kTTuVGm8+x9ZKq30ucT9 uioy5v1nVshjP4/HYmlq40X59z8Do2wxeNzYow9rffF0mBnqcg0mQ86T/K/IlVLXlLwL d7lDh3EWKVfH/TIqlziuA9zolRaOdQKdGf6W5quZyRd4OTbHjDMnfuCyIl7slQZ256I/ 0+sMZ69IE4hSVAcVKGj01puyQ24f0WSqVjiPY6YwBsBm76+CmjFluNmEl3GHclrOroep wX3g== X-Gm-Message-State: AIkVDXLyWiV6h8P9Fnr2wT/hyF4Zxsrl3ZzptaQPvKsIYNsMToDCv7lQGzPkF85DiZELng== X-Received: by 10.98.155.155 with SMTP id e27mr10541397pfk.140.1485542046939; Fri, 27 Jan 2017 10:34:06 -0800 (PST) Received: from [192.168.254.168] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id m29sm13066124pfi.54.2017.01.27.10.34.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 10:34:05 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Fri, 27 Jan 2017 10:34:08 -0800 From: Jeff Tantsura To: Martin Vigoureux , Message-ID: Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 18:34:09 -0000 Hi Martin, support as co-author. =20 Cheers, Jeff =20 On 1/27/17, 03:05, "spring on behalf of Martin Vigoureux" wrote: Hello Working Group, =20 This email starts a 2-week Working Group Last Call on=20 draft-ietf-spring-segment-routing-mpls-06 [1]. =20 =C2=A4 Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *12th of February*. Note that this is *not only* a call for comments on the document; it is= =20 also a call for support (or not) to publish this document as a Proposed= =20 Standard RFC. =20 =C2=A4 We have already polled for IPR knowledge on this document and all=20 Authors have replied. IPR exists against this document and has been disclosed [2]. =20 Thank you =20 M&B =20 --- [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-= mpls/ [2]=20 https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-spr= ing-segment-routing-mpls =20 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring =20 From nobody Fri Jan 27 11:59:36 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 BF8F3129869; Fri, 27 Jan 2017 11:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3nlyzyxKJfE; Fri, 27 Jan 2017 11:59:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9EE129862; Fri, 27 Jan 2017 11:59:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFI77241; Fri, 27 Jan 2017 19:59:30 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 27 Jan 2017 19:59:29 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Fri, 27 Jan 2017 11:59:23 -0800 From: Uma Chunduri To: Martin Vigoureux , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Thread-Index: AQHSeI1JuVelHzKrr0ygIt4K/eUNVKFMs62w Date: Fri, 27 Jan 2017 19:59:23 +0000 Message-ID: <25B4902B1192E84696414485F57268540187F20F@SJCEML703-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.99] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.588BA6A2.022D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: adb6e5fb30f71d29334efcc8b77fb9fe Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 19:59:35 -0000 Support. One quick comment:=20 While section 3 correctly documents MPLS instantiation of SR - given the c= onstructs SR has (ADJ SID for example) it's good to document SID/Label dept= h implications in the deployments. -- Uma C. -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Vigoureux Sent: Friday, January 27, 2017 3:05 AM To: spring@ietf.org Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-0= 6 Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-mpls-06 [1]. =A4 Please read the document if you haven't read the most recent version ye= t, and send your comments to the list, no later than the *12th of February*= . Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as a Proposed Standa= rd RFC. =A4 We have already polled for IPR knowledge on this document and all Autho= rs have replied. IPR exists against this document and has been disclosed [2]. Thank you M&B --- [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls= / [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-spr= ing-segment-routing-mpls _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Fri Jan 27 20:14:31 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 0252D129442; Fri, 27 Jan 2017 20:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 P-wiXp9RS8Um; Fri, 27 Jan 2017 20:14:28 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 80435129436; Fri, 27 Jan 2017 20:14:28 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id u68so29243271ywg.0; Fri, 27 Jan 2017 20:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FXE37uag1PY/6TZFMmwAMmcpF+HpFcM07r1xoJu0jMg=; b=eLjVq3LLW8lIFvHNSOaaYIErfhyoovxNffa+NA4lrzjl/ljFi0Qpis3lN+jBH2Efc7 I1MytdF5EWASHQbLDDzPqkiw1UhPJklCw6ZkHIKXgdGs2/wmdEWlEsR3Y/gJaS+RegY+ Ef8Z9UmwReemyxy5S2RP9uwCF/qe72Hh18bsAKXgMAEw18abwtFfmwn3UeprSKE1rEJt MYUsD1nH0DoqYL6mic+M4DrfSBB/SH4BJgKUQcSK9NgaBkSm1/U63DMxDccL4PxolWiL frzvFxJ8scR+WdpvI/qF+GpaQvCeY8Esg+1sJw719rNhaALcEBmrgBaqhOqE5aJ1n1g8 P2/Q== 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=FXE37uag1PY/6TZFMmwAMmcpF+HpFcM07r1xoJu0jMg=; b=Yjwhz6wkZ8FvLZcMvFejOUFsU/Pv3HDGKjDLKMFgt0dL3g5ikNl9YLQoSQ2c5ZWMr+ 6zBKeav7FjA6LTLx2FIUQ8XXWuCiaNIotlF+2VvMFuk1DdCciaoo+VA1pHtD3bVyLVCx luvKlZsqDaJXAvSSJdTRlY0q427pU8pCz8mw8qNoWJ6C5uBvxsJJONQ4B5LWo6gPLwW7 TmyypPb6/GB6ERMUyyvMAuFjQ13jhlEh5SMd3KUMu++Zjs/Vj4TsElQ11IwpPPqB+jSw 62Vb96vyNQGJ56ySteQyknHLngd151bOQQgLDDKiyTSprLGg38bbLXqyjrl9XMgJH8T7 v2bA== X-Gm-Message-State: AIkVDXIUiUXMWh4MS6s4Haw22mBRLTzuByZMpUKaahDmFkB+VyjkD3eBNCXPG+Ioxlc03cWKzhZl8DJXbVIO6w== X-Received: by 10.129.177.197 with SMTP id p188mr7577114ywh.183.1485576867786; Fri, 27 Jan 2017 20:14:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.197.138 with HTTP; Fri, 27 Jan 2017 20:14:27 -0800 (PST) In-Reply-To: References: From: Pushpasis Sarkar Date: Sat, 28 Jan 2017 09:44:27 +0530 Message-ID: To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=94eb2c1462047db97105471fd108 Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" , "spring@ietf.org" , Martin Vigoureux Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jan 2017 04:14:30 -0000 --94eb2c1462047db97105471fd108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Thanks and regards, -Pushpasis On Fri, Jan 27, 2017 at 6:30 PM, Acee Lindem (acee) wrote: > Hi, > > I have read the document and support publication. > > Thanks, > Acee > > On 1/27/17, 6:05 AM, "spring on behalf of Martin Vigoureux" > wrote: > > >Hello Working Group, > > > >This email starts a 2-week Working Group Last Call on > >draft-ietf-spring-segment-routing-mpls-06 [1]. > > > >=C2=A4 Please read the document if you haven't read the most recent > >version yet, and send your comments to the list, no later than the > >*12th of February*. > >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. > > > >=C2=A4 We have already polled for IPR knowledge on this document and all > >Authors have replied. > >IPR exists against this document and has been disclosed [2]. > > > >Thank you > > > >M&B > > > >--- > >[1] > >https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ > >[2] > >https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3D > draft-ietf-spring > >-segment-routing-mpls > > > >_______________________________________________ > >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 > --94eb2c1462047db97105471fd108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Thanks and regards,
-Pushp= asis

O= n Fri, Jan 27, 2017 at 6:30 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
Hi,

I have read the document and support publication.

Thanks,
Acee

On 1/27/17, 6:05 AM, "spring on behalf of Martin Vigoureux"
<spring-bounces@ietf.org on behalf of martin.vigoureux@nokia.com> wrote:

>Hello Working Group,
>
>This email starts a 2-week Working Group Last Call on
>draft-ietf-spring-segment-routing-mpls-06 [1].
>
>=C2=A4 Please read the document if you haven't read the most recent=
>version yet, and send your comments to the list, no later than the
>*12th of February*.
>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.
>
>=C2=A4 We have already polled for IPR knowledge on this document and al= l
>Authors have replied.
>IPR exists against this document and has been disclosed [2].
>
>Thank you
>
>M&B
>
>---
>[1]
>https://datatracker.ietf= .org/doc/draft-ietf-spring-segment-routing-mpls/
>[2]
>https://datatr= acker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-spr= ing
>-segment-routing-mpls
>
>_______________________________________________
>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

--94eb2c1462047db97105471fd108-- From nobody Mon Jan 30 00:58: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 D3BBC1289C4; Mon, 30 Jan 2017 00:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 DLO8ny4MgkAz; Mon, 30 Jan 2017 00:58:56 -0800 (PST) Received: from owl2.lab.dtag.de (Owl2.lab.DTAG.DE [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 09347120725; Mon, 30 Jan 2017 00:58:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id 63F34C6634; Mon, 30 Jan 2017 09:58:51 +0100 (CET) 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 6KvMF8-Pqfhe; Mon, 30 Jan 2017 09:58:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id E4929C755E; Mon, 30 Jan 2017 09:58:50 +0100 (CET) Received: from dhcp-128.intranet (p5DD9057C.dip0.t-ipconnect.de [93.217.5.124]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id B19FFC6634; Mon, 30 Jan 2017 09:58:50 +0100 (CET) To: Martin Vigoureux , spring@ietf.org References: From: Martin Horneffer Message-ID: Date: Mon, 30 Jan 2017 09:58:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 08:58:58 -0000 Hello, support from me as co-author and operator. Bets regards, Martin Am 27.01.17 um 12:05 schrieb Martin Vigoureux: > > Hello Working Group, > > This email starts a 2-week Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-06 [1]. > > ¤ Please read the document if you haven't read the most recent > version yet, and send your comments to the list, no later than the > *12th of February*. > 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. > > ¤ We have already polled for IPR knowledge on this document and all > Authors have replied. > IPR exists against this document and has been disclosed [2]. > > Thank you > > M&B > > --- > [1] > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ > [2] > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Mon Jan 30 01:04: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 E96C6128AB0; Mon, 30 Jan 2017 01:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 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=-3.199, 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 uUVIL3gR-qSk; Mon, 30 Jan 2017 01:04:16 -0800 (PST) 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 935FD120725; Mon, 30 Jan 2017 01:04:16 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id CAF6A20353; Mon, 30 Jan 2017 10:04:14 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 9EBA91C007E; Mon, 30 Jan 2017 10:04:14 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Mon, 30 Jan 2017 10:04:14 +0100 From: To: Martin Vigoureux , "spring@ietf.org" Thread-Topic: WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Thread-Index: AQHSeI1A3OX/PiWhxUeuzXGrIn+poaFQvogA Date: Mon, 30 Jan 2017 09:04:13 +0000 Message-ID: <12735_1485767054_588F018E_12735_1552_3_9E32478DFA9976438E7A22F69B08FF921DCB3457@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 09:04:18 -0000 Support -----Original Message----- From: Martin Vigoureux [mailto:martin.vigoureux@nokia.com]=20 Sent: Friday, January 27, 2017 12:05 To: spring@ietf.org Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-mpls-06 [1]. =A4 Please read the document if you haven't read the most recent version ye= t, and send your comments to the list, no later than the *12th of February*. Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as a Proposed Standa= rd RFC. =A4 We have already polled for IPR knowledge on this document and all Autho= rs have replied. IPR exists against this document and has been disclosed [2]. Thank you M&B --- [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-spr= ing-segment-routing-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 Mon Jan 30 01:13: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 2CAF21289C4; Mon, 30 Jan 2017 01:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 9AjEljjy4tn4; Mon, 30 Jan 2017 01:13:25 -0800 (PST) Received: from owl2.lab.dtag.de (Owl2.lab.DTAG.DE [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id D2C53120725; Mon, 30 Jan 2017 01:13:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id 4AEDCC5A84; Mon, 30 Jan 2017 10:13:21 +0100 (CET) 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 iStp0piTIMdj; Mon, 30 Jan 2017 10:13:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id B7DF8C5A8F; Mon, 30 Jan 2017 10:13:20 +0100 (CET) Received: from dhcp-128.intranet (p5DD9057C.dip0.t-ipconnect.de [93.217.5.124]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id 74697C5A84; Mon, 30 Jan 2017 10:13:20 +0100 (CET) To: Uma Chunduri , Martin Vigoureux , "spring@ietf.org" References: <25B4902B1192E84696414485F57268540187F20F@SJCEML703-CHM.china.huawei.com> From: Martin Horneffer Message-ID: <72705bfb-1c80-37ab-423f-27aec7378462@nic.dtag.de> Date: Mon, 30 Jan 2017 10:13:22 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <25B4902B1192E84696414485F57268540187F20F@SJCEML703-CHM.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 09:13:26 -0000 Hello Uma, what kind of label depth discussion are you thinking of? It seems to me this could easily become an endless discussion again. People seem to have very different views on it. Thus I'm not sure whether it would be suitable for this document. BTW: For my needs, bandwidth optimization is one of the major use cases for all traffic engineering technologies such as SR or RSVP. We are currently supporting scientific university research about this, and first results give strong confirmation that for bandwidth optimization in real world networks you rarely need more than 1 additional segment. Or rather, the additional efficiency gained by using mor than 1 additional segment is very small. We compare a global real backbone network with current routing, theoretical MCF optimization and realistic optimization with 1 (or 2 or 3) additional traffic engineering segments (aka 2-SR, 3-SR, 4-SR). Thus, from my point of view, an SR optimized network would typically have the same label stack depth as a similarily RSVP optimized network in some places, and a smaller label stack for the overall average . All other use-cases I found of serious interest so far all work with 1 additional segment (i.e. label) at most. Best regards, Martin Am 27.01.17 um 20:59 schrieb Uma Chunduri: > Support. > > One quick comment: > > While section 3 correctly documents MPLS instantiation of SR - given the constructs SR has (ADJ SID for example) it's good to document SID/Label depth implications in the deployments. > > -- > Uma C. > > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: Friday, January 27, 2017 3:05 AM > To: spring@ietf.org > Cc: draft-ietf-spring-segment-routing-mpls@ietf.org > Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 > > Hello Working Group, > > This email starts a 2-week Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-06 [1]. > > ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *12th of February*. > 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. > > ¤ We have already polled for IPR knowledge on this document and all Authors have replied. > IPR exists against this document and has been disclosed [2]. > > Thank you > > M&B > > --- > [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ > [2] > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls > > _______________________________________________ > 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 Jan 30 02:01:03 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 D7966129442; Mon, 30 Jan 2017 02:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.518 X-Spam-Level: X-Spam-Status: No, score=-7.518 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 kW0r9vcIRb5A; Mon, 30 Jan 2017 02:00:59 -0800 (PST) Received: from MAILOUT11.telekom.de (MAILOUT11.telekom.de [80.149.113.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AFE1289C4; Mon, 30 Jan 2017 02:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1485770459; x=1517306459; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GG99Nqs8GuB6kTQtYg2ee5lPnbG2VngFbSQUsb/+WDU=; b=WjhZzs7lnnL/xFmnD79naMsDxWsC1BCfjHmXa/5s6rjjK9LPf5P03GmV 3l/EqQ3ZZDTN3Dr0e4U6Ehu0VB7SzfJ9b+Ml1wheyWUIbPzt4q/52+RaH LhIEgu8mAPfT9RBg/qytfYh1xVXCgie43juRS7Ar9WfRnCnq5K949XucM hkZeTn5Ms8IaQ8w85npsrlAGNWyiVYEoosopDZTUlg8pRuq1pWc1zD669 q0FrayRPbfbNQLrLU0h5mUwI+pGDBShh296+SrWuUwNCE6MO9+6qrpZD3 Z9lzi9A4jGq0sFWZL9yGZIxpDEZ7j/pWQ5xM74V0jAqGH9Ga5dN+3lQ/a A==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 30 Jan 2017 11:00:55 +0100 X-IronPort-AV: E=Sophos;i="5.33,311,1477954800"; d="scan'208";a="1252191843" Received: from he101655.emea1.cds.t-internal.com ([10.134.226.17]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2017 10:48:29 +0100 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101655.emea1.cds.t-internal.com (10.134.226.17) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 30 Jan 2017 10:48:28 +0100 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1236.000; Mon, 30 Jan 2017 10:48:28 +0100 From: To: Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Thread-Index: AQHSetgMr9U6JBnlGUSy1QsD6hylqKFQxhkw Date: Mon, 30 Jan 2017 09:48:28 +0000 Message-ID: <70cf8b8d27874380a8e7ea38dbb5a9a5@HE101653.emea1.cds.t-internal.com> References: <12735_1485767054_588F018E_12735_1552_3_9E32478DFA9976438E7A22F69B08FF921DCB3457@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <12735_1485767054_588F018E_12735_1552_3_9E32478DFA9976438E7A22F69B08FF921DCB3457@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.165.104] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: draft-ietf-spring-segment-routing-mpls@ietf.org, spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 10:01:02 -0000 I also support the document. Regards, Ruediger -----Original Message----- From: Martin Vigoureux [mailto:martin.vigoureux@nokia.com] Sent: Friday, January 27, 2017 12:05 To: spring@ietf.org Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-mpls-06 [1]. =A4 Please read the document if you haven't read the most recent version ye= t, and send your comments to the list, no later than the *12th of February*= . Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as a Proposed Standa= rd RFC. =A4 We have already polled for IPR knowledge on this document and all Autho= rs have replied. IPR exists against this document and has been disclosed [2]. Thank you M&B --- [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls= / [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-spr= ing-segment-routing-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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute 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. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Mon Jan 30 02:09:28 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 B2E10129442 for ; Mon, 30 Jan 2017 02:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ef8_MRq-KMSn for ; Mon, 30 Jan 2017 02:09:26 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 EAD8A1293F4 for ; Mon, 30 Jan 2017 02:09:25 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id c85so207198332wmi.1 for ; Mon, 30 Jan 2017 02:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=xfvo9uOkku46RL2nTr5eYNoSyLYzkHjN6ZZ+K5lZJZY=; b=YKvHVPnU0lePXZGv3moXvXi4OML5LcpjwWwKaYvHtyBMjGNpecuZaNvJZgKOYE3Z+c MYXXr2litDGT7gnRbvVqjkTBo3yHdSgdjrRdZdy56rLehQZ9J67L57VZOaDt5GlesHsQ USDxd+LQ4RQvGrWig8GUz0vCHfRZyIfDwP3jxaZgnwcwv4qir7aYiX1t8x1r97skGmK3 /Ph43pmvylUv3tIFSxJQkpqfAH5JQpGfCCTgLRx7g7ildCZ0z8WSsSlRUsq9M0+1XJSq +ma+EcT4QJl36Rn55055aG/zK9Y2Ve4tz4vU58beioYHZkSlXCxk9jiDPgqpKRf81uTn K2Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xfvo9uOkku46RL2nTr5eYNoSyLYzkHjN6ZZ+K5lZJZY=; b=XJbLGfMHHoe9nq8J0alSWcISBCS7+ISKIcRRnACGcqs/4o0yps2vOsdU4kalzasfIL xOmytP+l1MN2jFHqZ/UmPGuaqKXsMm0pTttFrcXYRRG28MD1x9Z+z67Y/SGFoA4+JubK pnL12Bk5hR7f6RSynsqNotLlT4v3Ml979oFLBcLL0iSA/+q3ZUkxshspXVPy/PhWvbRt Bt8GloLvm5t+Dl1kYRsefTOMepCcYBwdltFu/qAtEJf60/riwaqOo+uq7YGJ4nJU5J9/ 6Cj9TuFbssKMBKEt5yO0gR98rtUVN4ruoq1/sF2SpMLiNKl3g52skgMEADeFglJd8+dv Gc3g== X-Gm-Message-State: AIkVDXL3GAbnfN69mrQlm4p/d5Rx1jqFzLGDQjYxiaOlghk6LbRg3W6SfOOA1t4qOOe/gg== X-Received: by 10.28.230.91 with SMTP id d88mr12597018wmh.129.1485770963682; Mon, 30 Jan 2017 02:09:23 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 10sm9981004wmi.23.2017.01.30.02.09.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 02:09:23 -0800 (PST) To: spring@ietf.org References: <25B4902B1192E84696414485F57268540187F20F@SJCEML703-CHM.china.huawei.com> From: Stewart Bryant Message-ID: <4c587b8e-0672-6382-237a-aecd5ba2d69c@gmail.com> Date: Mon, 30 Jan 2017 10:09:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <25B4902B1192E84696414485F57268540187F20F@SJCEML703-CHM.china.huawei.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-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 10:09:28 -0000 I agree. Whilst, as indicated later in the thread, some of the cases studied so far may only need a single label, this is a powerful general purpose technology that will be used for many purposes that have not yet been considered. Some discussion of the implication of the label stack limit imposed by current h/w and the need to consider this in future designs would be useful. Stewart On 27/01/2017 19:59, Uma Chunduri wrote: > Support. > > One quick comment: > > While section 3 correctly documents MPLS instantiation of SR - given the constructs SR has (ADJ SID for example) it's good to document SID/Label depth implications in the deployments. > > -- > Uma C. > > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: Friday, January 27, 2017 3:05 AM > To: spring@ietf.org > Cc: draft-ietf-spring-segment-routing-mpls@ietf.org > Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 > > Hello Working Group, > > This email starts a 2-week Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-06 [1]. > > ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *12th of February*. > 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. > > ¤ We have already polled for IPR knowledge on this document and all Authors have replied. > IPR exists against this document and has been disclosed [2]. > > Thank you > > M&B > > --- > [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ > [2] > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls > > _______________________________________________ > 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 Jan 30 03:28:02 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 27BB9129450; Mon, 30 Jan 2017 03:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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=-3.199, 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 4_ymerQTompq; Mon, 30 Jan 2017 03:27:56 -0800 (PST) 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 8E84F12944A; Mon, 30 Jan 2017 03:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3630; q=dns/txt; s=iport; t=1485775676; x=1486985276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sULZ05XnrL6jeliyWetHDmykGL5F7TiV1GUE1K4kIDw=; b=c+1Qu7e1UN2braueFrBOGZSMQbxiqhhtpNbv2+J4flE30d6KmK8XPdl9 RWALhSUtNezEZbeIJetxRKNmplJjIxBjzwqzhfX5CvrQdN7gyXD4AO0o5 3Wv4fpzVbumck6yOojm0m7kQFTLlBXCBMsELu8oiVyReWiALhCYMZoGOs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDaIo9Y/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQkHjVeSAZUyggwfDYUsSgKCED8YAQIBAQEBAQEBYiiEaQE?= =?us-ascii?q?BAQMBAQEbTwILBQcEAgEIDgMBAwEBAScHJwsUAwYIAgQOBYlcCA6tO4pwAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWGS4IFgmqDDIEPEQEcgzSCMQWbVAGGZosUgXm?= =?us-ascii?q?FFYNNhhySfgEfOHZVFTsQAYQrHIFhdYYFgSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,311,1477958400"; d="scan'208";a="205067145" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jan 2017 11:27:55 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0UBRt7T029676 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Jan 2017 11:27:55 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 30 Jan 2017 06:27:54 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 30 Jan 2017 06:27:54 -0500 From: "Stefano Previdi (sprevidi)" To: Martin Horneffer Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Thread-Index: AQHSeI1Ayr4HY2RVbEy4KOIyTWUgNKFNEmyAgAQCgACAACWlAA== Date: Mon, 30 Jan 2017 11:27:54 +0000 Message-ID: References: <25B4902B1192E84696414485F57268540187F20F@SJCEML703-CHM.china.huawei.com> <72705bfb-1c80-37ab-423f-27aec7378462@nic.dtag.de> In-Reply-To: <72705bfb-1c80-37ab-423f-27aec7378462@nic.dtag.de> 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.61.237.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2E912AE6CBDD22439A474D5E96298B04@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" , "spring@ietf.org" , Martin Vigoureux , Uma Chunduri Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 11:27:58 -0000 I agree with Martin, I think we have discussed this at length and I wouldn't re-spin the debate = (and come to the same conclusion again and again). The manageability sectio= n of the architecture draft mention that a node may want to signal its stac= k capabilities and we have igp extensions for that. s. > On Jan 30, 2017, at 10:13 AM, Martin Horneffer wrote: >=20 > Hello Uma, >=20 > what kind of label depth discussion are you thinking of? >=20 > It seems to me this could easily become an endless discussion again. Peop= le seem to have very different views on it. Thus I'm not sure whether it wo= uld be suitable for this document. >=20 > BTW: >=20 > For my needs, bandwidth optimization is one of the major use cases for al= l traffic engineering technologies such as SR or RSVP. >=20 > We are currently supporting scientific university research about this, an= d first results give strong confirmation that for bandwidth optimization in= real world networks you rarely need more than 1 additional segment. Or rat= her, the additional efficiency gained by using mor than 1 additional segmen= t is very small. We compare a global real backbone network with current rou= ting, theoretical MCF optimization and realistic optimization with 1 (or 2 = or 3) additional traffic engineering segments (aka 2-SR, 3-SR, 4-SR). > Thus, from my point of view, an SR optimized network would typically have= the same label stack depth as a similarily RSVP optimized network in some = places, and a smaller label stack for the overall average . >=20 > All other use-cases I found of serious interest so far all work with 1 ad= ditional segment (i.e. label) at most. >=20 > Best regards, Martin >=20 >=20 > Am 27.01.17 um 20:59 schrieb Uma Chunduri: >> Support. >>=20 >> One quick comment: >>=20 >> While section 3 correctly documents MPLS instantiation of SR - given th= e constructs SR has (ADJ SID for example) it's good to document SID/Label d= epth implications in the deployments. >>=20 >> -- >> Uma C. >>=20 >> -----Original Message----- >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Vigour= eux >> Sent: Friday, January 27, 2017 3:05 AM >> To: spring@ietf.org >> Cc: draft-ietf-spring-segment-routing-mpls@ietf.org >> Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpl= s-06 >>=20 >> Hello Working Group, >>=20 >> This email starts a 2-week Working Group Last Call on >> draft-ietf-spring-segment-routing-mpls-06 [1]. >>=20 >> =A4 Please read the document if you haven't read the most recent version= yet, and send your comments to the list, no later than the *12th of Februa= ry*. >> 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 Sta= ndard RFC. >>=20 >> =A4 We have already polled for IPR knowledge on this document and all Au= thors have replied. >> IPR exists against this document and has been disclosed [2]. >>=20 >> Thank you >>=20 >> M&B >>=20 >> --- >> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-m= pls/ >> [2] >> https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-= spring-segment-routing-mpls >>=20 >> _______________________________________________ >> 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 >>=20 >=20 From nobody Mon Jan 30 03:51:11 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 E7AD4129458; Mon, 30 Jan 2017 03:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RX6dEMYaOMp3; Mon, 30 Jan 2017 03:51:07 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 EFC3F129456; Mon, 30 Jan 2017 03:51:06 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id v77so43941159wmv.0; Mon, 30 Jan 2017 03:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=lVqrwG6PKIrWHoD02h+mn7+3AiiFXNeIaD3oM0tnIvs=; b=HEUO3gFYCt+OZcyDkpd6T9LH7G4++COOITTMITnlA04vPZ2Jt/mbQ0KHnht08VREKT t69vcZlae1lwTub1LoVVnrFmRvV9CkGrLq3lR3J/QXNLCE0B41GdsUqHDWjSN2sxqtne uotV5tJHSjGngYBJDpMne5IGLHK4F4sXR87I5N8jJzIE61CZml5UnP6OoquuJtPrO81m JfE/hhn+izespomm+0Fu/bLlNTrDTPI+BzmCK7Wsd1PNK8XNY/YDeE9+7+pPu5/y55Zb 0vW4CGxC89N5HyxFMFWF+BhglFkGDrEaFXJvCt+MerywuwL2x7/mHA22AknpfaTa5yTf TNRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lVqrwG6PKIrWHoD02h+mn7+3AiiFXNeIaD3oM0tnIvs=; b=WXEx9lHuuAl0gEHG4A4otd2XeBO43k1m3SLWf2/45FZYtFsokfL5UFBb9IbTp90wXU kLpHiAkq1T75QnhYY0RFVMMAnBdTcYnwPWVHGXm03ombkV7qhziNcZsPm1IVohrUFhYJ gG7nNNdQlEGT7HgOPxusslxdjGFgXdwRkfJP/ZMrRZjuCjpSUgtrbL/GaVZGR3wwaFMy 3JeEfd1ULAdsC6gXRgDZ+yCAjdN+7GWNXe/UbLRS4b77zFN1WT7wZg07DNAFo7TOR04C gGQbMtlYvBtgA9gSjqoUM7NTvHNhYZU+Nn/n1zfA3C9pb7i6pRMf+XMogiuL05hDCrzG znRA== X-Gm-Message-State: AIkVDXKNLrjoVz0BMwT5T/u+VHFf/sfglznSt05M4dvzeK5pSQJ/1wnVsFrKvYc6sF44aw== X-Received: by 10.28.152.137 with SMTP id a131mr14569680wme.139.1485777065381; Mon, 30 Jan 2017 03:51:05 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id q4sm22409331wrc.35.2017.01.30.03.51.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 03:51:04 -0800 (PST) To: "Stefano Previdi (sprevidi)" , Martin Horneffer References: <25B4902B1192E84696414485F57268540187F20F@SJCEML703-CHM.china.huawei.com> <72705bfb-1c80-37ab-423f-27aec7378462@nic.dtag.de> From: Stewart Bryant Message-ID: Date: Mon, 30 Jan 2017 11:51:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" , "spring@ietf.org" , Martin Vigoureux , Uma Chunduri , "mpls@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 11:51:09 -0000 Stefano, This is the document that someone interested in SR from and an MPLS perspective may well start with. A discussion on the issue of label stack depth and the practical constrains is thus very much in scope. The fact that you had a debate in the past immediately points to the need for a summary of the key issues and conclusions in this document. Stewart On 30/01/2017 11:27, Stefano Previdi (sprevidi) wrote: > I agree with Martin, > > I think we have discussed this at length and I wouldn't re-spin the debate (and come to the same conclusion again and again). The manageability section of the architecture draft mention that a node may want to signal its stack capabilities and we have igp extensions for that. > > s. > > >> On Jan 30, 2017, at 10:13 AM, Martin Horneffer wrote: >> >> Hello Uma, >> >> what kind of label depth discussion are you thinking of? >> >> It seems to me this could easily become an endless discussion again. People seem to have very different views on it. Thus I'm not sure whether it would be suitable for this document. >> >> BTW: >> >> For my needs, bandwidth optimization is one of the major use cases for all traffic engineering technologies such as SR or RSVP. >> >> We are currently supporting scientific university research about this, and first results give strong confirmation that for bandwidth optimization in real world networks you rarely need more than 1 additional segment. Or rather, the additional efficiency gained by using mor than 1 additional segment is very small. We compare a global real backbone network with current routing, theoretical MCF optimization and realistic optimization with 1 (or 2 or 3) additional traffic engineering segments (aka 2-SR, 3-SR, 4-SR). >> Thus, from my point of view, an SR optimized network would typically have the same label stack depth as a similarily RSVP optimized network in some places, and a smaller label stack for the overall average . >> >> All other use-cases I found of serious interest so far all work with 1 additional segment (i.e. label) at most. >> >> Best regards, Martin >> >> >> Am 27.01.17 um 20:59 schrieb Uma Chunduri: >>> Support. >>> >>> One quick comment: >>> >>> While section 3 correctly documents MPLS instantiation of SR - given the constructs SR has (ADJ SID for example) it's good to document SID/Label depth implications in the deployments. >>> >>> -- >>> Uma C. >>> >>> -----Original Message----- >>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Vigoureux >>> Sent: Friday, January 27, 2017 3:05 AM >>> To: spring@ietf.org >>> Cc: draft-ietf-spring-segment-routing-mpls@ietf.org >>> Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 >>> >>> Hello Working Group, >>> >>> This email starts a 2-week Working Group Last Call on >>> draft-ietf-spring-segment-routing-mpls-06 [1]. >>> >>> ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *12th of February*. >>> 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. >>> >>> ¤ We have already polled for IPR knowledge on this document and all Authors have replied. >>> IPR exists against this document and has been disclosed [2]. >>> >>> Thank you >>> >>> M&B >>> >>> --- >>> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ >>> [2] >>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls >>> >>> _______________________________________________ >>> 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 From nobody Mon Jan 30 09:40:11 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 C8532129506; Mon, 30 Jan 2017 09:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 HFiR4cfpZAlq; Mon, 30 Jan 2017 09:40:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB960129A21; Mon, 30 Jan 2017 09:40:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFM52221; Mon, 30 Jan 2017 17:39:59 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 30 Jan 2017 17:39:57 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Mon, 30 Jan 2017 09:39:51 -0800 From: Uma Chunduri To: Stewart Bryant , "Stefano Previdi (sprevidi)" , Martin Horneffer Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Thread-Index: AQHSeI1JuVelHzKrr0ygIt4K/eUNVKFMs62wgASTiQCAACWXAIAABncA///ZZqA= Date: Mon, 30 Jan 2017 17:39:49 +0000 Message-ID: <25B4902B1192E84696414485F57268540187F4FE@SJCEML703-CHM.china.huawei.com> References: <25B4902B1192E84696414485F57268540187F20F@SJCEML703-CHM.china.huawei.com> <72705bfb-1c80-37ab-423f-27aec7378462@nic.dtag.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.89] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.588F7A6F.0240, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: adb6e5fb30f71d29334efcc8b77fb9fe Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" , "spring@ietf.org" , Martin Vigoureux , "mpls@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 17:40:10 -0000 Hi Martin, Stefano, >It seems to me this could easily become an endless discussion again. Peopl= e seem to have very different views on it. Thus I'm not sure whether it wou= ld be suitable for this document. Sorry, that was not at all my intention to get into an endless discussion. Being an SR MPLS data plane document, I felt discussion or reference to SID= depth related aspects would be important. This is one of the aspects we co= ntended with, when SR is being discussed in MBH deployments in my previous = organization. > The manageability section of the architecture draft mention that a node m= ay want to signal its stack capabilities and we have igp extensions for tha= t. I am fine with referencing both or a summary as pointed by Stewart below at= some appropriate place in the document. -- Uma C. -----Original Message----- From: Stewart Bryant [mailto:stewart.bryant@gmail.com]=20 Sent: Monday, January 30, 2017 3:51 AM To: Stefano Previdi (sprevidi) ; Martin Horneffer Cc: draft-ietf-spring-segment-routing-mpls@ietf.org; spring@ietf.org; Marti= n Vigoureux ; Uma Chunduri ; mpls@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mp= ls-06 Stefano, This is the document that someone interested in SR from and an MPLS perspec= tive may well start with. A discussion on the issue of label stack depth an= d the practical constrains is thus very much in scope. The fact that you ha= d a debate in the past immediately points to the need for a summary of the = key issues and conclusions in this document. Stewart On 30/01/2017 11:27, Stefano Previdi (sprevidi) wrote: > I agree with Martin, > > I think we have discussed this at length and I wouldn't re-spin the debat= e (and come to the same conclusion again and again). The manageability sect= ion of the architecture draft mention that a node may want to signal its st= ack capabilities and we have igp extensions for that. > > s. > > >> On Jan 30, 2017, at 10:13 AM, Martin Horneffer wrote: >> >> Hello Uma, >> >> what kind of label depth discussion are you thinking of? >> >> It seems to me this could easily become an endless discussion again. Peo= ple seem to have very different views on it. Thus I'm not sure whether it w= ould be suitable for this document. >> >> BTW: >> >> For my needs, bandwidth optimization is one of the major use cases for a= ll traffic engineering technologies such as SR or RSVP. >> >> We are currently supporting scientific university research about this, a= nd first results give strong confirmation that for bandwidth optimization i= n real world networks you rarely need more than 1 additional segment. Or ra= ther, the additional efficiency gained by using mor than 1 additional segme= nt is very small. We compare a global real backbone network with current ro= uting, theoretical MCF optimization and realistic optimization with 1 (or 2= or 3) additional traffic engineering segments (aka 2-SR, 3-SR, 4-SR). >> Thus, from my point of view, an SR optimized network would typically hav= e the same label stack depth as a similarily RSVP optimized network in some= places, and a smaller label stack for the overall average . >> >> All other use-cases I found of serious interest so far all work with 1 a= dditional segment (i.e. label) at most. >> >> Best regards, Martin >> >> >> Am 27.01.17 um 20:59 schrieb Uma Chunduri: >>> Support. >>> >>> One quick comment: >>> >>> While section 3 correctly documents MPLS instantiation of SR - given t= he constructs SR has (ADJ SID for example) it's good to document SID/Label = depth implications in the deployments. >>> >>> -- >>> Uma C. >>> >>> -----Original Message----- >>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin=20 >>> Vigoureux >>> Sent: Friday, January 27, 2017 3:05 AM >>> To: spring@ietf.org >>> Cc: draft-ietf-spring-segment-routing-mpls@ietf.org >>> Subject: [spring] WG Last Call for=20 >>> draft-ietf-spring-segment-routing-mpls-06 >>> >>> Hello Working Group, >>> >>> This email starts a 2-week Working Group Last Call on >>> draft-ietf-spring-segment-routing-mpls-06 [1]. >>> >>> =A4 Please read the document if you haven't read the most recent versio= n yet, and send your comments to the list, no later than the *12th of Febru= ary*. >>> 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 St= andard RFC. >>> >>> =A4 We have already polled for IPR knowledge on this document and all A= uthors have replied. >>> IPR exists against this document and has been disclosed [2]. >>> >>> Thank you >>> >>> M&B >>> >>> --- >>> [1]=20 >>> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-m >>> pls/ >>> [2] >>> https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= - >>> spring-segment-routing-mpls >>> >>> _______________________________________________ >>> 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 From nobody Mon Jan 30 12:30: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 8DB38129B8B for ; Mon, 30 Jan 2017 12:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=weare138-org.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 4tC3rkliMY7g for ; Mon, 30 Jan 2017 12:30:34 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25029129B97 for ; Mon, 30 Jan 2017 12:30:34 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id l126so9546719qkc.1 for ; Mon, 30 Jan 2017 12:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=weare138-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RefAtKLCCLOk+Q8AsDPH1aHnP2sx3xULdq6gllp4Sds=; b=OEp/g2rlkoRNLUci8i7fr1H4XjF693hqmhNDmVv5L/3PCtcsxsN/SiwAc8l8hZWQOP f8NQL9xruG/CLLh7ldh3zWfbjNq0ujDGpHbv4wnBZs0nqKgilxm0489ct+eIzD8d2Bv1 ewChErHVD66SlfPStnEEH2FId8EwN3JcV63t/93uTnBM+k5mek8o7x/tCrp1+QPnTUT4 3vJCQ5Lwc8t4hE6PmmhqytSzQVXgZOk68GCoD7n25EPAuGBPEXNjX/feiSpUAdiSD/MU yjibRP+sxbMG+c7x1wOPeRibgz3UTxVcQhWgxrSigHpG1iR7mEBsIDlK/DZrIHmH53JB uhlg== 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=RefAtKLCCLOk+Q8AsDPH1aHnP2sx3xULdq6gllp4Sds=; b=f/K2fi5UcslXKObn4rex8W/v+d0x0rKOPmz8sfv9lMq9+fepx46PhE3hh+CfV7FHwQ 2kO4iF/R++NAqvjnB3Rxz2wxAxRNM35kAgouxiOPTp2YoG2bZTcob26u27LKKVrY6jkt 0lNfBYfzjr54v/CyBg8eIY+C9K984W57IB0QvAiAYa6wMCjlwJbyvBWaVmQGcrm+8Zot 6eGIyi36oe75fjbU+TJYxykcicrX8IB0NQ0JSwtnjBgext4yATycEDaI96R2lFiK837x umNA4uyLS+Tsu0iaCVKXcOAKTUd12r9GwB4bIx8uXqDsI8X451cknWpzyFoUTb+/r1t4 U8qQ== X-Gm-Message-State: AIkVDXIU3Fktft1b/KNYS0Og9Az8dcgi7o4rXYljRcJ4gT0SpjbbOM8Qy+EVOPuISBGohZ5prfDrbNeO7L0fiQ== X-Received: by 10.55.24.76 with SMTP id j73mr22895804qkh.267.1485808233156; Mon, 30 Jan 2017 12:30:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.57.227 with HTTP; Mon, 30 Jan 2017 12:30:32 -0800 (PST) X-Originating-IP: [160.34.93.43] In-Reply-To: References: From: Edward Crabbe Date: Mon, 30 Jan 2017 12:30:32 -0800 Message-ID: To: Martin Vigoureux Content-Type: multipart/alternative; boundary=001a1142a430f14790054755afd5 Archived-At: Cc: draft-ietf-spring-segment-routing-mpls@ietf.org, spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 20:30:36 -0000 --001a1142a430f14790054755afd5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Martin; Support as co-author. cheers, -ed On Fri, Jan 27, 2017 at 3:05 AM, Martin Vigoureux < martin.vigoureux@nokia.com> wrote: > Hello Working Group, > > This email starts a 2-week Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-06 [1]. > > =C2=A4 Please read the document if you haven't read the most recent > version yet, and send your comments to the list, no later than the > *12th of February*. > 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. > > =C2=A4 We have already polled for IPR knowledge on this document and all > Authors have replied. > IPR exists against this document and has been disclosed [2]. > > Thank you > > M&B > > --- > [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-r > outing-mpls/ > [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddra > ft-ietf-spring-segment-routing-mpls > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a1142a430f14790054755afd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin;

Support as co-autho= r.

cheers,
=C2=A0=C2=A0 -ed

On Fri, Jan 27, 2017 at 3:05 AM,= Martin Vigoureux <martin.vigoureux@nokia.com> wrot= e:
Hello Working Group,

This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-mpls-06 [1].

=C2=A4 Please read the document if you haven't read the most recent
version yet, and send your comments to the list, no later than the
*12th of February*.
Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as a Proposed Standa= rd RFC.

=C2=A4 We have already polled for IPR knowledge on this document and all Au= thors have replied.
IPR exists against this document and has been disclosed [2].

Thank you

M&B

---
[1] https://datatracker.ietf= .org/doc/draft-ietf-spring-segment-routing-mpls/
[2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id= =3Ddraft-ietf-spring-segment-routing-mpls

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

--001a1142a430f14790054755afd5-- From nobody Mon Jan 30 13:55:33 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 7E7B4129BE7 for ; Mon, 30 Jan 2017 13:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.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 BlyQttUrqniW for ; Mon, 30 Jan 2017 13:55:29 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9DE712962A for ; Mon, 30 Jan 2017 13:55:28 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id 65so252817671otq.2 for ; Mon, 30 Jan 2017 13:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Ws4K6rTwUxQZ35a74lKjBoxyud22QIDT75eQ85VSN8=; b=pdIN0JAmosAfC+d4IDaf0YR9k4JfkOvcQ8OpQtIu34mNrGch3LmKS8xXS4FZHkQJJb Mb7vtQowIYxR6R7C6XlcgLinQ++JdYuKpHbsWGBsq1EnPQFf84gNHkjjVWqObWRHvr0H Cqsr7ShAvqfZvqqXsxxxz7ivTJJxTVgy9yXHBn0bYI5GufHoV+N6621WGmbVG9WaEXNj 6zcxwLnLLl0K9Pp08vOgeL07pp7xj3I1nqqKWcXGc/TYzfwmxfw6hEkdO65/r5o66FtL YltGViCfiV1hwt6mV6QKaDqVgjKqsft0YX7EsZ1SBF2fVZ16h4aFNPkuvR7uYEuWUdhR uL4A== 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:cc; bh=7Ws4K6rTwUxQZ35a74lKjBoxyud22QIDT75eQ85VSN8=; b=J+4By0IR73MVQ9Vlu+buVpNz0XsCPrRswPJP8qfJYNRaqVD893gz5yFhZSbwHpoo7o HNiNh/Anj0KiX9kMKG+pY+B7E4lXlEHcUvENz1uwbH9NEcS5t4MDO81FdoJ9zFYe3Rkz UhTRxlB5iInwEVdOmX+rwBQABX8jj55UBmaDAcY5fnoA8yZ7Ug613RMeHF+fm7iaUWyQ y0XOulLjjO6OKkXy9cxSt0sl/lBPSCEK07yw0O9y9h7wE33XAGXqEIAXX3ui19Aa+8P0 m9zad8eNj9ZM2kQoMbPm4vHZ0luzxmEB7AA+JlcedZbK340NxJvsIhbVfhPbynJjc+Ox TFXA== X-Gm-Message-State: AIkVDXLinqyH3vkDFNevQanI/+Vm97rtkU2DaFkmNhJJsqiJxDJ3JcGpr+RoYjmxDcTOFTHBnxmFzkYPQqOw5A== X-Received: by 10.157.27.3 with SMTP id l3mr12669500otl.15.1485813328011; Mon, 30 Jan 2017 13:55:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Shakir Date: Mon, 30 Jan 2017 21:55:17 +0000 Message-ID: To: Edward Crabbe , Martin Vigoureux Content-Type: multipart/alternative; boundary=94eb2c09d0dc9e9757054756df83 Archived-At: Cc: draft-ietf-spring-segment-routing-mpls@ietf.org, spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 21:55:32 -0000 --94eb2c09d0dc9e9757054756df83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Martin, Support, as a co-author. r. On Mon, 30 Jan 2017 at 12:30 Edward Crabbe wrote: > Hi Martin; > > Support as co-author. > > cheers, > -ed > > On Fri, Jan 27, 2017 at 3:05 AM, Martin Vigoureux < > martin.vigoureux@nokia.com> wrote: > > Hello Working Group, > > This email starts a 2-week Working Group Last Call on > draft-ietf-spring-segment-routing-mpls-06 [1]. > > =C2=A4 Please read the document if you haven't read the most recent > version yet, and send your comments to the list, no later than the > *12th of February*. > 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. > > =C2=A4 We have already polled for IPR knowledge on this document and all > Authors have replied. > IPR exists against this document and has been disclosed [2]. > > Thank you > > M&B > > --- > [1] > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ > [2] > https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-s= pring-segment-routing-mpls > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --94eb2c09d0dc9e9757054756df83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

Support, as a co-author.

r.

On Mon, 30 Jan 2017 at 12:30 Edward Crabbe <edc@weare138.org> wrote:
Hi Martin;

Support as co-author.

cheers,
=C2=A0=C2=A0 -ed

On Fri, Jan 27, 2017 at 3:05 AM, Martin Vigoureux <martin.vigoureux@nokia.com>= wrote:
Hello Working Group,

This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-mpls-06 [1].

=C2=A4 Please read the document if you haven't read the most recent
version yet, and send your comments to the list, no later than the
*12th of February*.
Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as a Proposed Standa= rd RFC.

=C2=A4 We have already polled for IPR knowledge on this document and all Au= thors have replied.
IPR exists against this document and has been disclosed [2].

Thank you

M&B

---
[1] http= s://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ [2] https://datatracker.ietf.org/ipr/search/?submit= =3Ddraft&id=3Ddraft-ietf-spring-segment-routing-mpls

_______________________________________________
spring mailing list
sp= ring@ietf.org
https://www.ietf.org/mailman/listinf= o/spring
--94eb2c09d0dc9e9757054756df83-- From nobody Mon Jan 30 14:04:35 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 29D19129BDD; Mon, 30 Jan 2017 14:04:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148581387416.29775.17064865209518881482.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 14:04:34 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-ipv6-use-cases-08.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 22:04:34 -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 : IPv6 SPRING Use Cases Authors : John Brzozowski John Leddy Mark Townsley Clarence Filsfils Roberta Maglione Filename : draft-ietf-spring-ipv6-use-cases-08.txt Pages : 11 Date : 2017-01-30 Abstract: Source Packet Routing in Networking (SPRING) architecture leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with SPRING header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to the SPRING node or global within the SPRING domain. SPRING allows to enforce a flow through any topological path while maintaining per- flow state only at the ingress node to the SPRING domain. The objective of this document is to illustrate some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-ipv6-use-cases-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-ipv6-use-cases-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 Tue Jan 31 00:28: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 E37E3129444; Tue, 31 Jan 2017 00:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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=-3.199, 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 qb6KIHc6Bv3r; Tue, 31 Jan 2017 00:28:17 -0800 (PST) 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 39A29129430; Tue, 31 Jan 2017 00:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20149; q=dns/txt; s=iport; t=1485851297; x=1487060897; h=from:to:cc:subject:date:message-id:mime-version; bh=ygVa98eiCBiv0aW5XsBEmn56lRqNQp9ItqsJ+o4E7/0=; b=QQyCKQD+KjJXZDRYuROmLZdRxfikqsE1LVRWlEyZTh5CcGTHoGQ51YnB j1603jC9iR7YFUCV6EMohUur057dFgo/7JDYu5DUn6CfQTxqsjqZVeluo FHoeW6bp0hdCi+/Nz6ddIP/KICKOZsCISCAsRs3iz7zBfsSaf4WkODPD7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAQB5SZBY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnBkYYEJg1aKCZIFiAqHfoUrgg0fAQqFLkoCGoIUPxgBAgEBAQE?= =?us-ascii?q?BAQFiKIRpAQEBAwEBARsGCj8CCwUHBgEIEQEDAQEBJwMCBB8GCxQDBgoEAQ0FC?= =?us-ascii?q?IlOAw0IDqsWgiWHPA2DVAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhkuEb4JRPoE?= =?us-ascii?q?PEQEzH4JQgl8FlUOFXDgBhmaHA4QLggKFFYNNhh2KJ4hXAR84dlUVO4Q8HIFhd?= =?us-ascii?q?YYUgi0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,314,1477958400"; d="scan'208,217";a="206151806" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2017 08:28:15 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v0V8SFk2002240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Jan 2017 08:28:15 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 03:28:14 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 31 Jan 2017 03:28:14 -0500 From: "Stefano Previdi (sprevidi)" To: "maho@nic.dtag.de" , "stewart.bryant@gmail.com" , "uma.chunduri@huawei.com" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Thread-Index: AQHSe5v3yr4HY2RVbEy4KOIyTWUgNA== Date: Tue, 31 Jan 2017 08:28:14 +0000 Message-ID: <58c6f7f7a30b4aa4886da64dc954be31@XCH-RTP-010.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_58c6f7f7a30b4aa4886da64dc954be31XCHRTP010ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "martin.vigoureux@nokia.com" , "draft-ietf-spring-segment-routing-mpls@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 08:28:20 -0000 --_000_58c6f7f7a30b4aa4886da64dc954be31XCHRTP010ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVW1hLA0KDQpXZSdsbCBhZGQgYSBjb3VwbGUgb2Ygc3RhdGVtZW50cyBvbiB0aGF0IG1hdHRl ci4NCg0KVGhhbmtzLg0KDQpzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog VW1hIENodW5kdXJpIFt1bWEuY2h1bmR1cmlAaHVhd2VpLmNvbV0NClJlY2VpdmVkOiBNb25kYXks IDMwIEphbiAyMDE3LCA2OjQwUE0NClRvOiBTdGV3YXJ0IEJyeWFudCBbc3Rld2FydC5icnlhbnRA Z21haWwuY29tXTsgU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW3NwcmV2aWRpQGNpc2NvLmNv bV07IE1hcnRpbiBIb3JuZWZmZXIgW21haG9AbmljLmR0YWcuZGVdDQpDQzogZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHNAaWV0Zi5vcmcgW2RyYWZ0LWlldGYtc3ByaW5nLXNl Z21lbnQtcm91dGluZy1tcGxzQGlldGYub3JnXTsgc3ByaW5nQGlldGYub3JnIFtzcHJpbmdAaWV0 Zi5vcmddOyBNYXJ0aW4gVmlnb3VyZXV4IFttYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbV07IG1w bHNAaWV0Zi5vcmcgW21wbHNAaWV0Zi5vcmddDQpTdWJqZWN0OiBSRTogW3NwcmluZ10gV0cgTGFz dCBDYWxsIGZvciBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0wNg0KDQoN CkhpIE1hcnRpbiwgU3RlZmFubywNCg0KPkl0IHNlZW1zIHRvIG1lIHRoaXMgY291bGQgZWFzaWx5 IGJlY29tZSBhbiBlbmRsZXNzIGRpc2N1c3Npb24gYWdhaW4uIFBlb3BsZSBzZWVtIHRvIGhhdmUg dmVyeSBkaWZmZXJlbnQgdmlld3Mgb24gaXQuIFRodXMgSSdtIG5vdCBzdXJlIHdoZXRoZXIgaXQg d291bGQgYmUgc3VpdGFibGUgZm9yIHRoaXMgZG9jdW1lbnQuDQoNClNvcnJ5LCB0aGF0IHdhcyBu b3QgYXQgYWxsIG15IGludGVudGlvbiB0byBnZXQgaW50byBhbiBlbmRsZXNzIGRpc2N1c3Npb24u DQpCZWluZyBhbiBTUiBNUExTIGRhdGEgcGxhbmUgZG9jdW1lbnQsIEkgZmVsdCBkaXNjdXNzaW9u IG9yIHJlZmVyZW5jZSB0byBTSUQgZGVwdGggcmVsYXRlZCBhc3BlY3RzIHdvdWxkIGJlIGltcG9y dGFudC4gVGhpcyBpcyBvbmUgb2YgdGhlIGFzcGVjdHMgd2UgY29udGVuZGVkIHdpdGgsIHdoZW4g U1IgaXMgYmVpbmcgZGlzY3Vzc2VkIGluIE1CSCBkZXBsb3ltZW50cyBpbiBteSBwcmV2aW91cyBv cmdhbml6YXRpb24uDQoNCj4gVGhlIG1hbmFnZWFiaWxpdHkgc2VjdGlvbiBvZiB0aGUgYXJjaGl0 ZWN0dXJlIGRyYWZ0IG1lbnRpb24gdGhhdCBhIG5vZGUgbWF5IHdhbnQgdG8gc2lnbmFsIGl0cyBz dGFjayBjYXBhYmlsaXRpZXMgYW5kIHdlIGhhdmUgaWdwIGV4dGVuc2lvbnMgZm9yIHRoYXQuDQoN CkkgYW0gZmluZSB3aXRoIHJlZmVyZW5jaW5nIGJvdGggb3IgYSBzdW1tYXJ5IGFzIHBvaW50ZWQg YnkgU3Rld2FydCBiZWxvdyBhdCBzb21lIGFwcHJvcHJpYXRlIHBsYWNlIGluIHRoZSBkb2N1bWVu dC4NCg0KLS0NClVtYSBDLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBT dGV3YXJ0IEJyeWFudCBbbWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbV0NClNlbnQ6IE1v bmRheSwgSmFudWFyeSAzMCwgMjAxNyAzOjUxIEFNDQpUbzogU3RlZmFubyBQcmV2aWRpIChzcHJl dmlkaSkgPHNwcmV2aWRpQGNpc2NvLmNvbT47IE1hcnRpbiBIb3JuZWZmZXIgPG1haG9AbmljLmR0 YWcuZGU+DQpDYzogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHNAaWV0Zi5v cmc7IHNwcmluZ0BpZXRmLm9yZzsgTWFydGluIFZpZ291cmV1eCA8bWFydGluLnZpZ291cmV1eEBu b2tpYS5jb20+OyBVbWEgQ2h1bmR1cmkgPHVtYS5jaHVuZHVyaUBodWF3ZWkuY29tPjsgbXBsc0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzcHJpbmddIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0 Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMDYNCg0KU3RlZmFubywNCg0KVGhpcyBpcyB0 aGUgZG9jdW1lbnQgdGhhdCBzb21lb25lIGludGVyZXN0ZWQgaW4gU1IgZnJvbSBhbmQgYW4gTVBM UyBwZXJzcGVjdGl2ZSBtYXkgd2VsbCBzdGFydCB3aXRoLiBBIGRpc2N1c3Npb24gb24gdGhlIGlz c3VlIG9mIGxhYmVsIHN0YWNrIGRlcHRoIGFuZCB0aGUgcHJhY3RpY2FsIGNvbnN0cmFpbnMgaXMg dGh1cyB2ZXJ5IG11Y2ggaW4gc2NvcGUuIFRoZSBmYWN0IHRoYXQgeW91IGhhZCBhIGRlYmF0ZSBp biB0aGUgcGFzdCBpbW1lZGlhdGVseSBwb2ludHMgdG8gdGhlIG5lZWQgZm9yIGEgc3VtbWFyeSBv ZiB0aGUga2V5IGlzc3VlcyBhbmQgY29uY2x1c2lvbnMgaW4gdGhpcyBkb2N1bWVudC4NCg0KU3Rl d2FydA0KDQoNCk9uIDMwLzAxLzIwMTcgMTE6MjcsIFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkp IHdyb3RlOg0KPiBJIGFncmVlIHdpdGggTWFydGluLA0KPg0KPiBJIHRoaW5rIHdlIGhhdmUgZGlz Y3Vzc2VkIHRoaXMgYXQgbGVuZ3RoIGFuZCBJIHdvdWxkbid0IHJlLXNwaW4gdGhlIGRlYmF0ZSAo YW5kIGNvbWUgdG8gdGhlIHNhbWUgY29uY2x1c2lvbiBhZ2FpbiBhbmQgYWdhaW4pLiBUaGUgbWFu YWdlYWJpbGl0eSBzZWN0aW9uIG9mIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgbWVudGlvbiB0aGF0 IGEgbm9kZSBtYXkgd2FudCB0byBzaWduYWwgaXRzIHN0YWNrIGNhcGFiaWxpdGllcyBhbmQgd2Ug aGF2ZSBpZ3AgZXh0ZW5zaW9ucyBmb3IgdGhhdC4NCj4NCj4gcy4NCj4NCj4NCj4+IE9uIEphbiAz MCwgMjAxNywgYXQgMTA6MTMgQU0sIE1hcnRpbiBIb3JuZWZmZXIgPG1haG9AbmljLmR0YWcuZGU+ IHdyb3RlOg0KPj4NCj4+IEhlbGxvIFVtYSwNCj4+DQo+PiB3aGF0IGtpbmQgb2YgbGFiZWwgZGVw dGggZGlzY3Vzc2lvbiBhcmUgeW91IHRoaW5raW5nIG9mPw0KPj4NCj4+IEl0IHNlZW1zIHRvIG1l IHRoaXMgY291bGQgZWFzaWx5IGJlY29tZSBhbiBlbmRsZXNzIGRpc2N1c3Npb24gYWdhaW4uIFBl b3BsZSBzZWVtIHRvIGhhdmUgdmVyeSBkaWZmZXJlbnQgdmlld3Mgb24gaXQuIFRodXMgSSdtIG5v dCBzdXJlIHdoZXRoZXIgaXQgd291bGQgYmUgc3VpdGFibGUgZm9yIHRoaXMgZG9jdW1lbnQuDQo+ Pg0KPj4gQlRXOg0KPj4NCj4+IEZvciBteSBuZWVkcywgYmFuZHdpZHRoIG9wdGltaXphdGlvbiBp cyBvbmUgb2YgdGhlIG1ham9yIHVzZSBjYXNlcyBmb3IgYWxsIHRyYWZmaWMgZW5naW5lZXJpbmcg dGVjaG5vbG9naWVzIHN1Y2ggYXMgU1Igb3IgUlNWUC4NCj4+DQo+PiBXZSBhcmUgY3VycmVudGx5 IHN1cHBvcnRpbmcgc2NpZW50aWZpYyB1bml2ZXJzaXR5IHJlc2VhcmNoIGFib3V0IHRoaXMsIGFu ZCBmaXJzdCByZXN1bHRzIGdpdmUgc3Ryb25nIGNvbmZpcm1hdGlvbiB0aGF0IGZvciBiYW5kd2lk dGggb3B0aW1pemF0aW9uIGluIHJlYWwgd29ybGQgbmV0d29ya3MgeW91IHJhcmVseSBuZWVkIG1v cmUgdGhhbiAxIGFkZGl0aW9uYWwgc2VnbWVudC4gT3IgcmF0aGVyLCB0aGUgYWRkaXRpb25hbCBl ZmZpY2llbmN5IGdhaW5lZCBieSB1c2luZyBtb3IgdGhhbiAxIGFkZGl0aW9uYWwgc2VnbWVudCBp cyB2ZXJ5IHNtYWxsLiBXZSBjb21wYXJlIGEgZ2xvYmFsIHJlYWwgYmFja2JvbmUgbmV0d29yayB3 aXRoIGN1cnJlbnQgcm91dGluZywgdGhlb3JldGljYWwgTUNGIG9wdGltaXphdGlvbiBhbmQgcmVh bGlzdGljIG9wdGltaXphdGlvbiB3aXRoIDEgKG9yIDIgb3IgMykgYWRkaXRpb25hbCB0cmFmZmlj IGVuZ2luZWVyaW5nIHNlZ21lbnRzIChha2EgMi1TUiwgMy1TUiwgNC1TUikuDQo+PiBUaHVzLCBm cm9tIG15IHBvaW50IG9mIHZpZXcsIGFuIFNSIG9wdGltaXplZCBuZXR3b3JrIHdvdWxkIHR5cGlj YWxseSBoYXZlIHRoZSBzYW1lIGxhYmVsIHN0YWNrIGRlcHRoIGFzIGEgc2ltaWxhcmlseSBSU1ZQ IG9wdGltaXplZCBuZXR3b3JrIGluIHNvbWUgcGxhY2VzLCBhbmQgYSBzbWFsbGVyIGxhYmVsIHN0 YWNrIGZvciB0aGUgb3ZlcmFsbCBhdmVyYWdlIC4NCj4+DQo+PiBBbGwgb3RoZXIgdXNlLWNhc2Vz IEkgZm91bmQgb2Ygc2VyaW91cyBpbnRlcmVzdCBzbyBmYXIgYWxsIHdvcmsgd2l0aCAxIGFkZGl0 aW9uYWwgc2VnbWVudCAoaS5lLiBsYWJlbCkgYXQgbW9zdC4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMs IE1hcnRpbg0KPj4NCj4+DQo+PiBBbSAyNy4wMS4xNyB1bSAyMDo1OSBzY2hyaWViIFVtYSBDaHVu ZHVyaToNCj4+PiBTdXBwb3J0Lg0KPj4+DQo+Pj4gT25lIHF1aWNrIGNvbW1lbnQ6DQo+Pj4NCj4+ PiBXaGlsZSBzZWN0aW9uIDMgY29ycmVjdGx5IGRvY3VtZW50cyBNUExTIGluc3RhbnRpYXRpb24g b2YgU1IgLSAgZ2l2ZW4gdGhlIGNvbnN0cnVjdHMgU1IgaGFzIChBREogU0lEIGZvciBleGFtcGxl KSBpdCdzIGdvb2QgdG8gZG9jdW1lbnQgU0lEL0xhYmVsIGRlcHRoIGltcGxpY2F0aW9ucyBpbiB0 aGUgZGVwbG95bWVudHMuDQo+Pj4NCj4+PiAtLQ0KPj4+IFVtYSBDLg0KPj4+DQo+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbg0KPj4+IFZpZ291cmV1eA0KPj4+IFNl bnQ6IEZyaWRheSwgSmFudWFyeSAyNywgMjAxNyAzOjA1IEFNDQo+Pj4gVG86IHNwcmluZ0BpZXRm Lm9yZw0KPj4+IENjOiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBsc0BpZXRm Lm9yZw0KPj4+IFN1YmplY3Q6IFtzcHJpbmddIFdHIExhc3QgQ2FsbCBmb3INCj4+PiBkcmFmdC1p ZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0wNg0KPj4+DQo+Pj4gSGVsbG8gV29ya2lu ZyBHcm91cCwNCj4+Pg0KPj4+IFRoaXMgZW1haWwgc3RhcnRzIGEgMi13ZWVrIFdvcmtpbmcgR3Jv dXAgTGFzdCBDYWxsIG9uDQo+Pj4gZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1w bHMtMDYgWzFdLg0KPj4+DQo+Pj4gwqQgUGxlYXNlIHJlYWQgdGhlIGRvY3VtZW50IGlmIHlvdSBo YXZlbid0IHJlYWQgdGhlIG1vc3QgcmVjZW50IHZlcnNpb24geWV0LCBhbmQgc2VuZCB5b3VyIGNv bW1lbnRzIHRvIHRoZSBsaXN0LCBubyBsYXRlciB0aGFuIHRoZSAqMTJ0aCBvZiBGZWJydWFyeSou DQo+Pj4gTm90ZSB0aGF0IHRoaXMgaXMgKm5vdCBvbmx5KiBhIGNhbGwgZm9yIGNvbW1lbnRzIG9u IHRoZSBkb2N1bWVudDsgaXQgaXMgYWxzbyBhIGNhbGwgZm9yIHN1cHBvcnQgKG9yIG5vdCkgdG8g cHVibGlzaCB0aGlzIGRvY3VtZW50IGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQgUkZDLg0KPj4+DQo+ Pj4gwqQgV2UgaGF2ZSBhbHJlYWR5IHBvbGxlZCBmb3IgSVBSIGtub3dsZWRnZSBvbiB0aGlzIGRv Y3VtZW50IGFuZCBhbGwgQXV0aG9ycyBoYXZlIHJlcGxpZWQuDQo+Pj4gSVBSIGV4aXN0cyBhZ2Fp bnN0IHRoaXMgZG9jdW1lbnQgYW5kIGhhcyBiZWVuIGRpc2Nsb3NlZCBbMl0uDQo+Pj4NCj4+PiBU aGFuayB5b3UNCj4+Pg0KPj4+IE0mQg0KPj4+DQo+Pj4gLS0tDQo+Pj4gWzFdDQo+Pj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0 aW5nLW0NCj4+PiBwbHMvDQo+Pj4gWzJdDQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9pcHIvc2VhcmNoLz9zdWJtaXQ9ZHJhZnQmaWQ9ZHJhZnQtaWV0Zi0NCj4+PiBzcHJpbmctc2Vn bWVudC1yb3V0aW5nLW1wbHMNCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPj4+IHNwcmluZ0Bp ZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4+PiBzcHJpbmdAaWV0Zi5vcmcNCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPj4+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNwcmluZyBtYWlsaW5n IGxpc3QNCj4gc3ByaW5nQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3ByaW5nDQoNCg== --_000_58c6f7f7a30b4aa4886da64dc954be31XCHRTP010ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLCBBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0O2NvbG9yOmJsYWNrIj5IaSBVbWEs PGJyPg0KPGJyPg0KV2UnbGwgYWRkIGEgY291cGxlIG9mIHN0YXRlbWVudHMgb24gdGhhdCBtYXR0 ZXIuPGJyPg0KPGJyPg0KVGhhbmtzLjxicj4NCjxicj4NCnMuPGJyPg0KPGJyPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8YnI+DQo8Yj5Gcm9t OjwvYj4gVW1hIENodW5kdXJpIFt1bWEuY2h1bmR1cmlAaHVhd2VpLmNvbV08YnI+DQo8Yj5SZWNl aXZlZDo8L2I+IE1vbmRheSwgMzAgSmFuIDIwMTcsIDY6NDBQTTxicj4NCjxiPlRvOjwvYj4gU3Rl d2FydCBCcnlhbnQgW3N0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbV07IFN0ZWZhbm8gUHJldmlkaSAo c3ByZXZpZGkpIFtzcHJldmlkaUBjaXNjby5jb21dOyBNYXJ0aW4gSG9ybmVmZmVyIFttYWhvQG5p Yy5kdGFnLmRlXTxicj4NCjxiPkNDOjwvYj4gZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0 aW5nLW1wbHNAaWV0Zi5vcmcgW2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxz QGlldGYub3JnXTsgc3ByaW5nQGlldGYub3JnIFtzcHJpbmdAaWV0Zi5vcmddOyBNYXJ0aW4gVmln b3VyZXV4IFttYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbV07IG1wbHNAaWV0Zi5vcmcgW21wbHNA aWV0Zi5vcmddPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc3ByaW5nXSBXRyBMYXN0IENhbGwg Zm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTA2PGJyPg0KPGJyPg0K PC9zcGFuPjwvc3Bhbj48YnI+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+SGkgTWFydGluLCBTdGVmYW5vLDxicj4N Cjxicj4NCiZndDtJdCBzZWVtcyB0byBtZSB0aGlzIGNvdWxkIGVhc2lseSBiZWNvbWUgYW4gZW5k bGVzcyBkaXNjdXNzaW9uIGFnYWluLiBQZW9wbGUgc2VlbSB0byBoYXZlIHZlcnkgZGlmZmVyZW50 IHZpZXdzIG9uIGl0LiBUaHVzIEknbSBub3Qgc3VyZSB3aGV0aGVyIGl0IHdvdWxkIGJlIHN1aXRh YmxlIGZvciB0aGlzIGRvY3VtZW50Ljxicj4NCjxicj4NClNvcnJ5LCB0aGF0IHdhcyBub3QgYXQg YWxsIG15IGludGVudGlvbiB0byBnZXQgaW50byBhbiBlbmRsZXNzIGRpc2N1c3Npb24uPGJyPg0K QmVpbmcgYW4gU1IgTVBMUyBkYXRhIHBsYW5lIGRvY3VtZW50LCBJIGZlbHQgZGlzY3Vzc2lvbiBv ciByZWZlcmVuY2UgdG8gU0lEIGRlcHRoIHJlbGF0ZWQgYXNwZWN0cyB3b3VsZCBiZSBpbXBvcnRh bnQuIFRoaXMgaXMgb25lIG9mIHRoZSBhc3BlY3RzIHdlIGNvbnRlbmRlZCB3aXRoLCB3aGVuIFNS IGlzIGJlaW5nIGRpc2N1c3NlZCBpbiBNQkggZGVwbG95bWVudHMgaW4gbXkgcHJldmlvdXMgb3Jn YW5pemF0aW9uLjxicj4NCjxicj4NCiZndDsgVGhlIG1hbmFnZWFiaWxpdHkgc2VjdGlvbiBvZiB0 aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0IG1lbnRpb24gdGhhdCBhIG5vZGUgbWF5IHdhbnQgdG8gc2ln bmFsIGl0cyBzdGFjayBjYXBhYmlsaXRpZXMgYW5kIHdlIGhhdmUgaWdwIGV4dGVuc2lvbnMgZm9y IHRoYXQuPGJyPg0KPGJyPg0KSSBhbSBmaW5lIHdpdGggcmVmZXJlbmNpbmcgYm90aCBvciBhIHN1 bW1hcnkgYXMgcG9pbnRlZCBieSBTdGV3YXJ0IGJlbG93IGF0IHNvbWUgYXBwcm9wcmlhdGUgcGxh Y2UgaW4gdGhlIGRvY3VtZW50Ljxicj4NCjxicj4NCi0tPGJyPg0KVW1hIEMuPGJyPg0KPGJyPg0K PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBTdGV3YXJ0IEJyeWFu dCBbPGEgaHJlZj0ibWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSI+bWFpbHRvOnN0ZXdh cnQuYnJ5YW50QGdtYWlsLmNvbTwvYT5dDQo8YnI+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMzAs IDIwMTcgMzo1MSBBTTxicj4NClRvOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSAmbHQ7c3By ZXZpZGlAY2lzY28uY29tJmd0OzsgTWFydGluIEhvcm5lZmZlciAmbHQ7bWFob0BuaWMuZHRhZy5k ZSZndDs8YnI+DQpDYzogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHNAaWV0 Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgTWFydGluIFZpZ291cmV1eCAmbHQ7bWFydGluLnZpZ291 cmV1eEBub2tpYS5jb20mZ3Q7OyBVbWEgQ2h1bmR1cmkgJmx0O3VtYS5jaHVuZHVyaUBodWF3ZWku Y29tJmd0OzsgbXBsc0BpZXRmLm9yZzxicj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBXRyBMYXN0 IENhbGwgZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTA2PGJyPg0K PGJyPg0KU3RlZmFubyw8YnI+DQo8YnI+DQpUaGlzIGlzIHRoZSBkb2N1bWVudCB0aGF0IHNvbWVv bmUgaW50ZXJlc3RlZCBpbiBTUiBmcm9tIGFuZCBhbiBNUExTIHBlcnNwZWN0aXZlIG1heSB3ZWxs IHN0YXJ0IHdpdGguIEEgZGlzY3Vzc2lvbiBvbiB0aGUgaXNzdWUgb2YgbGFiZWwgc3RhY2sgZGVw dGggYW5kIHRoZSBwcmFjdGljYWwgY29uc3RyYWlucyBpcyB0aHVzIHZlcnkgbXVjaCBpbiBzY29w ZS4gVGhlIGZhY3QgdGhhdCB5b3UgaGFkIGEgZGViYXRlIGluIHRoZSBwYXN0IGltbWVkaWF0ZWx5 DQogcG9pbnRzIHRvIHRoZSBuZWVkIGZvciBhIHN1bW1hcnkgb2YgdGhlIGtleSBpc3N1ZXMgYW5k IGNvbmNsdXNpb25zIGluIHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KU3Rld2FydDxicj4NCjxi cj4NCjxicj4NCk9uIDMwLzAxLzIwMTcgMTE6MjcsIFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkp IHdyb3RlOjxicj4NCiZndDsgSSBhZ3JlZSB3aXRoIE1hcnRpbiw8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJIHRoaW5rIHdlIGhhdmUgZGlzY3Vzc2VkIHRoaXMgYXQgbGVuZ3RoIGFuZCBJIHdvdWxkbid0 IHJlLXNwaW4gdGhlIGRlYmF0ZSAoYW5kIGNvbWUgdG8gdGhlIHNhbWUgY29uY2x1c2lvbiBhZ2Fp biBhbmQgYWdhaW4pLiBUaGUgbWFuYWdlYWJpbGl0eSBzZWN0aW9uIG9mIHRoZSBhcmNoaXRlY3R1 cmUgZHJhZnQgbWVudGlvbiB0aGF0IGEgbm9kZSBtYXkgd2FudCB0byBzaWduYWwgaXRzIHN0YWNr IGNhcGFiaWxpdGllcyBhbmQgd2UgaGF2ZSBpZ3ANCiBleHRlbnNpb25zIGZvciB0aGF0Ljxicj4N CiZndDs8YnI+DQomZ3Q7IHMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBK YW4gMzAsIDIwMTcsIGF0IDEwOjEzIEFNLCBNYXJ0aW4gSG9ybmVmZmVyICZsdDttYWhvQG5pYy5k dGFnLmRlJmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhlbGxvIFVtYSw8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHdoYXQga2luZCBvZiBsYWJlbCBkZXB0aCBkaXNj dXNzaW9uIGFyZSB5b3UgdGhpbmtpbmcgb2Y/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJ dCBzZWVtcyB0byBtZSB0aGlzIGNvdWxkIGVhc2lseSBiZWNvbWUgYW4gZW5kbGVzcyBkaXNjdXNz aW9uIGFnYWluLiBQZW9wbGUgc2VlbSB0byBoYXZlIHZlcnkgZGlmZmVyZW50IHZpZXdzIG9uIGl0 LiBUaHVzIEknbSBub3Qgc3VyZSB3aGV0aGVyIGl0IHdvdWxkIGJlIHN1aXRhYmxlIGZvciB0aGlz IGRvY3VtZW50Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQlRXOjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgRm9yIG15IG5lZWRzLCBiYW5kd2lkdGggb3B0aW1pemF0aW9uIGlzIG9u ZSBvZiB0aGUgbWFqb3IgdXNlIGNhc2VzIGZvciBhbGwgdHJhZmZpYyBlbmdpbmVlcmluZyB0ZWNo bm9sb2dpZXMgc3VjaCBhcyBTUiBvciBSU1ZQLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg V2UgYXJlIGN1cnJlbnRseSBzdXBwb3J0aW5nIHNjaWVudGlmaWMgdW5pdmVyc2l0eSByZXNlYXJj aCBhYm91dCB0aGlzLCBhbmQgZmlyc3QgcmVzdWx0cyBnaXZlIHN0cm9uZyBjb25maXJtYXRpb24g dGhhdCBmb3IgYmFuZHdpZHRoIG9wdGltaXphdGlvbiBpbiByZWFsIHdvcmxkIG5ldHdvcmtzIHlv dSByYXJlbHkgbmVlZCBtb3JlIHRoYW4gMSBhZGRpdGlvbmFsIHNlZ21lbnQuIE9yIHJhdGhlciwg dGhlIGFkZGl0aW9uYWwgZWZmaWNpZW5jeQ0KIGdhaW5lZCBieSB1c2luZyBtb3IgdGhhbiAxIGFk ZGl0aW9uYWwgc2VnbWVudCBpcyB2ZXJ5IHNtYWxsLiBXZSBjb21wYXJlIGEgZ2xvYmFsIHJlYWwg YmFja2JvbmUgbmV0d29yayB3aXRoIGN1cnJlbnQgcm91dGluZywgdGhlb3JldGljYWwgTUNGIG9w dGltaXphdGlvbiBhbmQgcmVhbGlzdGljIG9wdGltaXphdGlvbiB3aXRoIDEgKG9yIDIgb3IgMykg YWRkaXRpb25hbCB0cmFmZmljIGVuZ2luZWVyaW5nIHNlZ21lbnRzIChha2EgMi1TUiwgMy1TUiwN CiA0LVNSKS48YnI+DQomZ3Q7Jmd0OyBUaHVzLCBmcm9tIG15IHBvaW50IG9mIHZpZXcsIGFuIFNS IG9wdGltaXplZCBuZXR3b3JrIHdvdWxkIHR5cGljYWxseSBoYXZlIHRoZSBzYW1lIGxhYmVsIHN0 YWNrIGRlcHRoIGFzIGEgc2ltaWxhcmlseSBSU1ZQIG9wdGltaXplZCBuZXR3b3JrIGluIHNvbWUg cGxhY2VzLCBhbmQgYSBzbWFsbGVyIGxhYmVsIHN0YWNrIGZvciB0aGUgb3ZlcmFsbCBhdmVyYWdl IC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFsbCBvdGhlciB1c2UtY2FzZXMgSSBmb3Vu ZCBvZiBzZXJpb3VzIGludGVyZXN0IHNvIGZhciBhbGwgd29yayB3aXRoIDEgYWRkaXRpb25hbCBz ZWdtZW50IChpLmUuIGxhYmVsKSBhdCBtb3N0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg QmVzdCByZWdhcmRzLCBNYXJ0aW48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgQW0gMjcuMDEuMTcgdW0gMjA6NTkgc2NocmllYiBVbWEgQ2h1bmR1cmk6PGJyPg0KJmd0 OyZndDsmZ3Q7IFN1cHBvcnQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9u ZSBxdWljayBjb21tZW50Ojxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBXaGls ZSBzZWN0aW9uIDMgY29ycmVjdGx5IGRvY3VtZW50cyBNUExTIGluc3RhbnRpYXRpb24gb2YgU1Ig LSZuYnNwOyBnaXZlbiB0aGUgY29uc3RydWN0cyBTUiBoYXMgKEFESiBTSUQgZm9yIGV4YW1wbGUp IGl0J3MgZ29vZCB0byBkb2N1bWVudCBTSUQvTGFiZWwgZGVwdGggaW1wbGljYXRpb25zIGluIHRo ZSBkZXBsb3ltZW50cy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS08YnI+ DQomZ3Q7Jmd0OyZndDsgVW1hIEMuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7IEZyb206IHNwcmlu ZyBbPGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFydGluDQo8YnI+DQomZ3Q7Jmd0 OyZndDsgVmlnb3VyZXV4PGJyPg0KJmd0OyZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAy NywgMjAxNyAzOjA1IEFNPGJyPg0KJmd0OyZndDsmZ3Q7IFRvOiBzcHJpbmdAaWV0Zi5vcmc8YnI+ DQomZ3Q7Jmd0OyZndDsgQ2M6IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxz QGlldGYub3JnPGJyPg0KJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFtzcHJpbmddIFdHIExhc3QgQ2Fs bCBmb3IgPGJyPg0KJmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1tcGxzLTA2PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEhlbGxvIFdvcmtp bmcgR3JvdXAsPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRoaXMgZW1haWwg c3RhcnRzIGEgMi13ZWVrIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uPGJyPg0KJmd0OyZndDsm Z3Q7IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTA2IFsxXS48YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgwqQgUGxlYXNlIHJlYWQgdGhlIGRvY3VtZW50 IGlmIHlvdSBoYXZlbid0IHJlYWQgdGhlIG1vc3QgcmVjZW50IHZlcnNpb24geWV0LCBhbmQgc2Vu ZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBubyBsYXRlciB0aGFuIHRoZSAqMTJ0aCBvZiBG ZWJydWFyeSouPGJyPg0KJmd0OyZndDsmZ3Q7IE5vdGUgdGhhdCB0aGlzIGlzICpub3Qgb25seSog YSBjYWxsIGZvciBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQ7IGl0IGlzIGFsc28gYSBjYWxsIGZv ciBzdXBwb3J0IChvciBub3QpIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBhIFByb3Bvc2Vk IFN0YW5kYXJkIFJGQy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgwqQgV2Ug aGF2ZSBhbHJlYWR5IHBvbGxlZCBmb3IgSVBSIGtub3dsZWRnZSBvbiB0aGlzIGRvY3VtZW50IGFu ZCBhbGwgQXV0aG9ycyBoYXZlIHJlcGxpZWQuPGJyPg0KJmd0OyZndDsmZ3Q7IElQUiBleGlzdHMg YWdhaW5zdCB0aGlzIGRvY3VtZW50IGFuZCBoYXMgYmVlbiBkaXNjbG9zZWQgWzJdLjxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGFuayB5b3U8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgTSZhbXA7Qjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyAtLS08YnI+DQomZ3Q7Jmd0OyZndDsgWzFdIDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctbSIgdGFyZ2V0PSJfQkxBTksiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW08L2E+PGJyPg0KJmd0 OyZndDsmZ3Q7IHBscy88YnI+DQomZ3Q7Jmd0OyZndDsgWzJdPGJyPg0KJmd0OyZndDsmZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/c3VibWl0PWRy YWZ0JmFtcDtpZD1kcmFmdC1pZXRmLSIgdGFyZ2V0PSJfQkxBTksiPg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9zdWJtaXQ9ZHJhZnQmYW1wO2lkPWRyYWZ0LWlldGYt PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyBzcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHM8YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsgc3ByaW5nIG1haWxpbmcgbGlz dDxicj4NCiZndDsmZ3Q7Jmd0OyBzcHJpbmdAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdl dD0iX0JMQU5LIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwv YT48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsgc3ByaW5nIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyBzcHJpbmdAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0 OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJp bmciIHRhcmdldD0iX0JMQU5LIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwcmluZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzcHJpbmcgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyBzcHJpbmdAaWV0Zi5vcmc8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiB0YXJnZXQ9Il9CTEFOSyI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PGJyPg0KPGJyPg0K PC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_58c6f7f7a30b4aa4886da64dc954be31XCHRTP010ciscocom_--