Re: [Isis-wg] Conflicting MS entries

<bruno.decraene@orange.com> Tue, 23 June 2015 13:48 UTC

Return-Path: <bruno.decraene@orange.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 1FE991A8A39; Tue, 23 Jun 2015 06:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 CCr626oQu8KA; Tue, 23 Jun 2015 06:48:15 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE151A8A27; Tue, 23 Jun 2015 06:48:14 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id EFFB218CA34; Tue, 23 Jun 2015 15:48:12 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C71D427C059; Tue, 23 Jun 2015 15:48:12 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0235.001; Tue, 23 Jun 2015 15:48:10 +0200
From: <bruno.decraene@orange.com>
To: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
Thread-Topic: Conflicting MS entries
Thread-Index: AQHQqFgIw0yxX2QFqkW6a4BJLQOJuJ2wTXowgAB4/oD///jw4IABHlUQgAABNmCAAbGpwIAAjYgwgAX9PxA=
Date: Tue, 23 Jun 2015 13:48:09 +0000
Message-ID: <25992_1435067292_5589639C_25992_16719_7_be5cfe09-97ab-4548-bd46-8b1f38282e68@OPEXCLILM31.corporate.adroot.infra.ftgroup>
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>
In-Reply-To: <4A79394211F1AF4EB57D998426C9340D94855471@US70UWXCHMBA01.zam.alcatel-lucent.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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.23.121516
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/ll_XiYLPakb9O-IiJxZB8xSEGtE>
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 13:48:17 -0000

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.