Hi Bruno, Indeed what you are describing would be similar to having tunnels to the same destination prefix resolved via two different protocols (LDP and SR). As you said, maybe I am just not seeing a use case for allowing this. I can however see that one can program two SIDs for the same prefix using two different SPF algorithms.
Regards, Mustapha. > -----Original Message----- > From: spring [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Wednesday, June 24, 2015 3:38 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, > > > 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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
