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:[email protected]] On Behalf Of > [email protected] > Sent: Tuesday, June 23, 2015 9:48 AM > To: Aissaoui, Mustapha (Mustapha) > Cc: LITKOWSKI Stephane SCE/IBNF; [email protected]; [email protected] 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:[email protected]] On Behalf Of > > > [email protected] > > > Sent: Friday, June 19, 2015 5:17 AM > > > To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi) > > > Cc: [email protected]; [email protected] 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:[email protected]] On Behalf Of > > > [email protected] > > > Sent: Thursday, June 18, 2015 09:29 > > > To: LITKOWSKI Stephane SCE/IBNF; Stefano Previdi (sprevidi) > > > Cc: [email protected]; [email protected] list > > > Subject: Re: [spring] Conflicting MS entries > > > > > > Hi Stéphane, > > > > > > > From: [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
