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:[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 _________________________________________________________________________________________________________________________ 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
