Re: [Isis-wg] Conflicting MS entries

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> Tue, 23 June 2015 20:34 UTC

Return-Path: <mustapha.aissaoui@alcatel-lucent.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 494691B3099; Tue, 23 Jun 2015 13:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 AVGyKphIdqeG; Tue, 23 Jun 2015 13:34:13 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 54C521B309F; Tue, 23 Jun 2015 13:34:12 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 5FBA45B3AA22A; Tue, 23 Jun 2015 20:34:07 +0000 (GMT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t5NKY8xS005984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 20:34:08 GMT
Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 16:34:08 -0400
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>
Thread-Topic: Conflicting MS entries
Thread-Index: AQHQqFgIw0yxX2QFqkW6a4BJLQOJuJ2wTXowgAB4/oD///jw4IABHlUQgAABNmCAAbGpwIAAjYgwgAX9PxCAAAxH8A==
Date: Tue, 23 Jun 2015 20:34:07 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340DD471A450@US70UWXCHMBA01.zam.alcatel-lucent.com>
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>
In-Reply-To: <25992_1435067292_5589639C_25992_16719_7_be5cfe09-97ab-4548-bd46-8b1f38282e68@OPEXCLILM31.corporate.adroot.infra.ftgroup>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/4demXhU_pumVNflo6RIT32PLMJ0>
X-Mailman-Approved-At: Wed, 24 Jun 2015 09:19:58 -0700
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, 23 Jun 2015 20:34:16 -0000

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?

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