Re: [Isis-wg] Conflicting MS entries

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