Re: [Isis-wg] Conflicting MS entries

Uma Chunduri <uma.chunduri@ericsson.com> Tue, 30 June 2015 18:24 UTC

Return-Path: <uma.chunduri@ericsson.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8701B2AEB; Tue, 30 Jun 2015 11:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 tkiEp3RX4OkF; Tue, 30 Jun 2015 11:24:33 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D191B2AEA; Tue, 30 Jun 2015 11:24:33 -0700 (PDT)
X-AuditID: c6180641-f794d6d000001dfb-48-559277f21d30
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 04.83.07675.2F772955; Tue, 30 Jun 2015 13:05:22 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Tue, 30 Jun 2015 14:24:29 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>
Thread-Topic: Conflicting MS entries
Thread-Index: AQHQqFgIw0yxX2QFqkW6a4BJLQOJuJ2wTXowgAB4/oD///jw4IABHlUQgAABNmCAAbGpwIAAjYgwgAX9PxCAAAxH8IABIthAgABoG6CACbokEA==
Date: Tue, 30 Jun 2015 18:24:29 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F746CB6@eusaamb105.ericsson.se>
References: <AACFE588-60A1-4652-940A-F127F4845558@cisco.com> <5862_1434530566_55813306_5862_129_1_0719486d-2955-432f-b6fd-44650477256f@OPEXCLILM24.corporate.adroot.infra.ftgroup> <885458B9-75C8-4654-9B12-EF1DC4D30277@cisco.com> <28410_1434552838_55818A06_28410_37_1_46370f62-b81b-4b0c-a50c-2e0aa0acd8c3@OPEXCLILM32.corporate.adroot.infra.ftgroup> <31285_1434612154_558271BA_31285_253_2_7f802e17-6d95-49f0-97e3-edf29a0302dd@OPEXCLILM33.corporate.adroot.infra.ftgroup> <31293_1434612559_5582734F_31293_5808_12_0e15d1df-4591-4e0e-9e6e-a894e1b560c2@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <22234_1434705452_5583DE2C_22234_4536_1_0d3ef822-b1fc-49b5-85d7-ecc8c0ccc710@OPEXCLILM22.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340D94855471@US70UWXCHMBA01.zam.alcatel-lucent.com> <25992_1435067292_5589639C_25992_16719_7_be5cfe09-97ab-4548-bd46-8b1f38282e68@OPEXCLILM31.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD471A450@US70UWXCHMBA01.zam.alcatel-lucent.com> <5558_1435131462_558A5E46_5558_1532_1_5388a789-63fc-4ad3-ba41-4edc1b8ca892@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD471E4BA@US70UWXCHMBA01.zam.alcatel-lucent.com>
In-Reply-To: <4A79394211F1AF4EB57D998426C9340DD471E4BA@US70UWXCHMBA01.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonXPdT+aRQg20PtC1+7JjDbHH00HtW i5Z565gs1u9+xGRx/MJvRouvex+yOrB5tD7by+ox5fdGVo8lS34yebQ8O8kWwBLFZZOSmpNZ llqkb5fAlfGh6RBTwe2QiufTlzA2MN5y6mLk5JAQMJGY2LCYHcIWk7hwbz1bFyMXh5DAUUaJ t5/PMEM4yxkl7lxtZAOpYhPQk/g49Sc7SEJEoJVR4uPWbawgDrPAcUaJSwdnMIFUCQsoS+x6 PIcZxBYRUJFYdeUBC4RdJzHxwGJWEJtFQFXi0oW7YDavgK/EtisroNbt55R42HibESTBKRAr 8W/uKbBmRqADv59aA7aAWUBc4taT+UwQhwtILNlznhnCFpV4+fgfK4StJPHx93x2iHo9iRtT p7BB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtzECIy0 YxJsjjsYF3yyPMQowMGoxMO7oH1iqBBrYllxZe4hRmkOFiVxXmm/vFAhgfTEktTs1NSC1KL4 otKc1OJDjEwcnFINjCVRj31DH9Ud3v7Is1h770au6KgXj5hlQ97mNURefhcXtfquYP3il8nS f2+ymPUbHHf2v8S5j+FTnvDy+Za96hz9jM8DQ65qtK9YcHDR3KLe+O8xO69mtf602KlZd8j1 8V7WhVIOcjkTWWQvnl2S/mOXcFvtj+nfLn3M9vIqexobKGDqsUlZSomlOCPRUIu5qDgRABMZ SI2VAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/M3wSK5mpZ6eFQJaYKYa-46nF51Q>
Cc: "spring@ietf.org" <spring@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>, "Stefano Previdi \(sprevidi\)" <sprevidi@cisco.com>
Subject: Re: [Isis-wg] Conflicting MS entries
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2015 18:24:36 -0000

Installing multiple SIDs for the same prefix in the FWD is bit off topic though related to the point being discussed.

Have few questions here to answer the "Conflicting MS Entries"

1. Is it a valid configuration to  provision multiple global prefix SIDs for any prefix  ?
     It seems the consensus here is though one can do this there is no real use case.

2. Is it a valid configuration to host a prefix on two nodes with different global prefix SIDs?
     In the similar lines is it valid a configuration to host multiple MSes and advertise different global SID indices for the same prefix?
    I failed to see any valid use case here too.

3. Is it a valid configuration to host a connected or otherwise route on two nodes with same prefix SID?

To me answer for #1 and #2 is invalid.  
 #3 is valid and intention is to host a multi-homed prefix so that all nodes can
 compute ECMP path or prefer lower cost path to one of the nodes.

I prefer staying out of defining any mechanism  which would be any ways  indeterministic for invalid configurations. 

--
Uma C.


-----Original Message-----
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Wednesday, June 24, 2015 6:37 AM
To: bruno.decraene@orange.com
Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis-wg@ietf.org list; Stefano Previdi (sprevidi)
Subject: Re: [spring] Conflicting MS entries

Hi Bruno,
Indeed what you are describing would be similar to having tunnels to the same destination prefix resolved via two different protocols (LDP and SR). As you said, maybe I am just not seeing a use case for allowing this. I can however see that one can program two SIDs for the same prefix using two different SPF algorithms.

Regards,
Mustapha.

> -----Original Message-----
> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of 
> bruno.decraene@orange.com
> Sent: Wednesday, June 24, 2015 3:38 AM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis-wg@ietf.org 
> list; Stefano Previdi (sprevidi)
> Subject: Re: [spring] Conflicting MS entries
> 
> Hi Mustapha,
> 
> > From: Aissaoui, Mustapha (Mustapha) 
> > [mailto:mustapha.aissaoui@alcatel-
> > lucent.com]
> > Sent: Tuesday, June 23, 2015 10:34 PM
> >
> > Hi Bruno,
> > I can see that one can program multiple SIDs if these are for routes 
> > of the same prefix which are advertised in multiple ISIS instances 
> > or in multiple topologies. But within a single instance and 
> > topology, how do you reconcile the multiple MS entries with a single 
> > active route to that
> destination prefix?
> 
> I'm probably missing something, but I don't see a need to reconcile. I 
> see 2 LSPs and for each a (N:1) indirection between the (label, FEC 
> element) and the IP FIB. A bit similar to multiple BGP routes using 
> the same IP prefix to resolve their BGP Next-Hop.
> 
> e.g. MS advertises 2 SIDs for prefix1 --> (via SRGBs) 2 incoming & 2 
> outgoings labels. LL1, LL2 for local/incoming labels. LN1, LN2 for neighbor/outgoing label.
> IP FIB:
> Prefix1 --> eth1
> 
> NHLFE:
> LFE1: eth1, swap LN1
> LFE2: eth1, swap LN2
> 
> ILM:
> LL1 --> LFE1
> LL2 --> LFE2
> 
> 
> Looks also similar to the case where a node(LSR) is both SR & LDP and 
> for the same FEC element/IP prefix  gets 1 label from LDP and 1 from SR/MS.
> 
> That being said, if we are all in favor of selecting a single MS 
> entry, the discussion is purely theoretical.
> 
> /Bruno
> 
> > Mustapha.
> >
> > > -----Original Message-----
> > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of 
> > > bruno.decraene@orange.com
> > > Sent: Tuesday, June 23, 2015 9:48 AM
> > > To: Aissaoui, Mustapha (Mustapha)
> > > Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis-wg@ietf.org 
> > > list; Stefano Previdi (sprevidi)
> > > Subject: Re: [spring] Conflicting MS entries
> > >
> > > Hi Mustapha,
> > >
> > > Thanks for the discussion. Please see inline.
> > >
> > > > From: Aissaoui, Mustapha (Mustapha) 
> > > > [mailto:mustapha.aissaoui@alcatel-> lucent.com] > Sent: Friday, 
> > > > June 19, 2015 8:19 PM
> > > >
> > > > Hi Stephane and Bruno,
> > > > I do not think programming multiple SIDs makes sense. While 
> > > > there are multiple MS prefix sub-TLVs, there is only single 
> > > > active route for the prefix with potentially ECMP next-hops 
> > > > which was resolved from a received IP reachability TLV.
> > >
> > > I don't see what prevents us from programming multiple SIDs/labels 
> > > for a single prefix. i.e. setting up multiple LSPs for a given prefix.
> > > e.g. BGP seems to specifically allow for this
> > > https://tools.ietf.org/html/rfc3107#section-4
> > >
> > > That being said:
> > > - I'm not seeing benefit (which, may be, is what you meant by 
> > > "makes no sense")
> > > - St├ęphane expressed that from an operational point, this may make 
> > > things
> > harder.
> > > - eventually some implementation may find this harder compared to 
> > > having a single one.
> > >
> > > So, so far, it looks like everyone expressed a preference to use 
> > > only one, based on deterministic criteria.
> > >
> > > > I agree that selecting one of the entries is preferable to dropping traffic.
> > > Ok.
> > >
> > > > We
> > > > could come up with selection criteria but the reality is that 
> > > > there no way for the router to check if any of the MS entries is 
> > > > legitimate or
> not.
> > >
> > > What do you mean by "legitimate"?
> > > In case of multiple SID advertisement for a prefix, they seem all 
> > > equally legitimate to me. Looks like giving multiple names to 
> > > something. e.g. we'll call this LSP/segment "A" or "R" or "Y".
> > > Now we may choose to only use one, based on a criteria TBD. e.g.
> > > smallest SID (which a priori improve the probability of fitting 
> > > inside the
> > SRGBs).
> > >
> > > /Bruno
> > >
> > > > As a result, I
> > > > would think that once an entry is selected based on the criteria 
> > > > and programmed, we should not be changing it unless the MS entry 
> > > > is
> > withdrawn.
> > > >
> > > > Mustapha.
> > > >
> > > > > -----Original Message-----
> > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of 
> > > > > stephane.litkowski@orange.com
> > > > > Sent: Friday, June 19, 2015 5:17 AM
> > > > > To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
> > > > > Cc: spring@ietf.org; isis-wg@ietf.org list
> > > > > Subject: Re: [spring] Conflicting MS entries
> > > > >
> > > > > Even if choosing any IP to MPLS entry does not break anything, 
> > > > > I'm not sure this is a good idea from an operational point of 
> > > > > view to let it
> > > > undeterministic.
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of 
> > > > > bruno.decraene@orange.com
> > > > > Sent: Thursday, June 18, 2015 09:29
> > > > > To: LITKOWSKI Stephane SCE/IBNF; Stefano Previdi (sprevidi)
> > > > > Cc: spring@ietf.org; isis-wg@ietf.org list
> > > > > Subject: Re: [spring] Conflicting MS entries
> > > > >
> > > > > Hi St├ęphane,
> > > > >
> > > > > > From: stephane.litkowski@orange.com> Sent: Thursday, June 
> > > > > > 18,
> > > > > > 2015
> > > > > > 9:23 AM
> > > > > >
> > > > > > Hi Bruno,
> > > > > >
> > > > > > "	 1) I don't really the issue. From a forwarding standpoint, looks
> > like
> > > > > > we can simply program multiple SIDs in the FIB."
> > > > > >
> > > > > > [SLI] What about the IP to MPLS entry ?
> > > > >
> > > > > [Bruno] If transit LSRs install all SIDs, an ingress may use 
> > > > > any SID, no? Local decision.
> > > > >
> > > > > Bruno
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > ____________________________________________________________
> > > > ________
> > >
> > >
> > >
> > ____________________________________________________________
> > ________
> > > _____________________________________________________
> > >
> > > Ce message et ses pieces jointes peuvent contenir des informations 
> > > confidentielles ou privilegiees et ne doivent donc pas etre 
> > > diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> > > ce message par erreur, veuillez le signaler a l'expediteur et le 
> > > detruire ainsi que les pieces jointes. Les messages electroniques 
> > > etant susceptibles d'alteration, Orange decline toute 
> > > responsabilite si ce message a ete altere,
> > deforme ou falsifie. Merci.
> > >
> > > This message and its attachments may contain confidential or 
> > > privileged information that may be protected by law; they should 
> > > not be distributed, used or copied without authorisation.
> > > If you have received this email in error, please notify the sender 
> > > and delete this message and its attachments.
> > > As emails may be altered, Orange is not liable for messages that 
> > > have been modified, changed or falsified.
> > > Thank you.
> > >
> > > _______________________________________________
> > > spring mailing list
> > > spring@ietf.org
> > > https://www.ietf.org/mailman/listinfo/spring
> 
> ____________________________________________________________________
> _____________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> 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