Subject: Re: [spring] Conflicting MS entries

From: <[email-masked]>
Date: Wed, 17 Jun 2015 14:53:55 +0000

Hi Stefano,

Thanks for initiating discussion on this point.

1) I don't feel that this is a IS-IS encoding specific issue, but rather a SPRING consideration, so I'm adding spring.
Eventually this seems related to draft-filsfils-spring-segment-routing-ldp-interop

<chair hat off>

2) From a service provider standpoint, i.e. from a functional standpoint, I think what we should try to handle this as nicely as possible. Indeed, having conflicting configurations between 2 nodes may happen, and even the most clever implementation may not avoid such configuration mistake. So in such case, dropping traffic for Mapping Server SID seems a significant network wide disruption.

3) As a contributor to spring, from a protocol standpoint, this looks a priori easier than BGP error handling, so we should probably be able to do at least as good.
It seems easier since:
- the state of the speaker is not relevant as we don't need to send spring traffic or spring signaling to it.
- all receivers receive the same information which is syntaxally correct

So to have a coherent network state, it would seem sufficient to specify a behavior on the receiving side.

4) Going into more details, and referring to Stéphane analysis:
	 1) I don't really the issue. From a forwarding standpoint, looks like we can simply program multiple SIDs in the FIB.
	 2) Seems more complex to me. A priori we need to define a tie-breaker based on received MS entries. We seem to all agree that local only mapping must be disregarded/less preferred. According to you, this is the easy part, so looks good.
	3) Is already specified in the ISIS document: https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-04#section-2.4.5

So it looks like the remaining work is to define a tie-breaker.

Thanks,
Bruno

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
> 
> <removing the long recipient list and adding isis-wg> Background
> information about this issue is on the original email here below.
> 
> 
> Hi Stephane,
> 
> On Jun 17, 2015, at 10:42 AM, <[email-masked]> wrote:
> > Hi Stefano,
> >
> > As discussed in Dallas, there may be no ideal option but let's try to find
> one which may try to preserve the transport service. So I'm not in favor of
> option 1.
> > There may be three kinds of overlap :
> > 1) prefix overlap with different indexes, example :
> > 	192.0.2.0/32 range 10 index 100
> > 	192.0.2.5/32 range 1 index 2000
> > 	192.0.2.5/32 range 2 index 3000
> > 	In this case 192.0.2.5/32 is associated with three different indexes
> >
> > 2) index overlap, example :
> > 	192.0.2.0/32 range 10 index 100
> > 	198.15.0.0/32 range 100 index 100
> > 	In this case, different prefixes will use the same index.
> >
> > 3) overlap between binding TLV and prefix entry
> > 	192.0.2.0/32 range 10 index 100 learned from MS
> > 	192.0.2.5/32 index 200 learned from TLV135
> > 	In this case 192.0.2.5/32 is associated with two different indexes
> > learned by two different ways
> 
> 
> very good points above and that illustrate even better the complexity of the
> scheme we would need to define in order to cope with all possible cases.
> 
> 
> > 2) must be solved as we manage conflicting SIDs associated with
> connected prefixes. It's a similar case, two different prefixes having the
> same SID.
> 
> 
> yes, this is the easy one. Again, no real solution here but as you pointed out,
> you may still want to preserve part of the reachability.
> 
> >
> > 1)3) If we think about tiebreaker, I'm not sure that preferring local MS
> entries over remote MS entries is a good idea as it may lead to
> inconsistencies while the target may be to have everyone taking the same
> decision.  In contrary, I would make prefer prefix SID mappings over MS
> entries.
> 
> 
> yes, I agree. The point was what to prefer between a received MS entry vs. a
> locally defined MS entry. But as you aid, if we prefer anything "local" we
> can't rely on network-wide consistent behavior.
> 
> s.
> 
> 
> > To compare MS entries, it may be possible to consider something like
> lowest range and then lowest index for example.
> >
> > -----Original Message-----
> > From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
> > Sent: Tuesday, June 16, 2015 19:15
> > To: Clarence Filsfils (cfilsfil); Ahmed Bashandy (bashandy); Hannes
> > Gredler; LITKOWSKI Stephane SCE/IBNF; DECRAENE Bruno IMT/OLN; Jeff
> > Tantsura; Les Ginsberg (ginsberg); Wim (Wim) Henderickx; Steven Luong
> > (sluong)
> > Subject: Conflicting MS entries
> >
> > Co-authors and Contributors,
> >
> > I'd like to close on the conflicting MS entries issues.
> >
> > The issue is related to what a receiver should do when receiving to or
> more conflicting MS mappings.
> >
> > So far we agreed that there's no way we can determine which one is good
> or bad and therefore whatever action we mandate it will create disruption.
> The choices are:
> >
> > 1. ignore all conflicting entries
> > 2. select one of the conflicting entry based on whatever breaking tie algo.
> >
> > Obviously, option1 is the easiest knowing that no other option would allow
> to fix the conflict anyway.
> > Option2 may be appealing but in such case we would have to consider all
> corner cases such as:
> > . what about a conflict between locally configured mapping entry and
> received ones ?
> > . what about conflicting entries received by the same router ? which one to
> select ?
> >
> > I think it is preferable to ignore all conflicting entries and log and error
> message. We discussed about this in Dallas but despite the agreement on
> the absence of a cure we decided, at that time, to let the operators to give
> feedback on the proposal.
> >
> > Is there anything that has changed ?
> >
> > Also, let me know if you'd prefer to bring the issue to the mailing list
> before reaching agreement among co-authors.
> >
> > Thanks.
> > s.
> >
> >
> >
> ______________________________________________________________
> ________
> > ___________________________________________________
> >
> > 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.
> >
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Thu, 18 Jun 2015 07:22:32 +0000

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 ?

---

From: [email-masked]
Date: Thu, 18 Jun 2015 14:32:12 +0800

Hi Bruno ,

Agree with you, it is necessary to define a tie-break.

And as described in the draft 
https://tools.ietf.org/html/draft-lw-spring-sid-allocation-01,
 
it has described the tie-breaker between two or more SRMNs by SR 
Capabilities Sub-TLV extension 
with the Allocation bit set, the tie-breaker is decided on the receivers 
by judging the SRMNs' router id or system id, the detail information is 
described in section 4.2：

If more than one SRMN assigned by the NMS, the SRMNs May
   flood out another extension which indicating having the capability to
   allocate SID, this extension is called the SR Allocation Ability
   extension and be included in the SR capabilities.  When other SR
   nodes receive more than one of the SRMN advertised the extension, the
   SR node could decide how to choose the Allocated SID, the choosing
   principle is based on the value of SRMNs' router id or system id, the
   maximum or the minimum value is chosen, and the SID allocated by the
   maximum or minimum id's SRMN be chosen.  When each SR node received
   the IGP packet with the SID Allocation TLV, it will know which SID is
   allocated to itself, and then the SR node sends out the prefix-SID
   sub-TLV in its IGP packet flooding out in the IGP area.

and the protocol extension is described in section 6：

...the assigned router advertises its SID allocation capability, it may be
   included in SR-Capabilities Sub-TLV of ISIS or in SR-Capabilities TLV
   of OSPF, with the Special Flag to indicate it is an assigned router.
...
         0
         0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |I|V|A|         |
         +-+-+-+-+-+-+-+-+

   where:
   o  A-Flag: Allocation flag.  If set, then the router is capable of
      allocating SID capability.

Best Regards.
Ting

"spring" <[email-masked]> 写于 2015-06-17 22:53:55:

> 1) I don't feel that this is a IS-IS encoding specific issue, but 
> rather a SPRING consideration, so I'm adding spring.
> 2) From a service provider standpoint, i.e. from a functional 
> standpoint, I think what we should try to handle this as nicely as 
> possible. Indeed, having conflicting configurations between 2 nodes 
> may happen, and even the most clever implementation may not avoid 
> such configuration mistake. So in such case, dropping traffic for 
> Mapping Server SID seems a significant network wide disruption.
> 
> 3) As a contributor to spring, from a protocol standpoint, this 
> looks a priori easier than BGP error handling, so we should probably
> be able to do at least as good.
> It seems easier since:
> - the state of the speaker is not relevant as we don't need to send 
> spring traffic or spring signaling to it.
> So to have a coherent network state, it would seem sufficient to 
> specify a behavior on the receiving side.
> 
>     1) I don't really the issue. From a forwarding standpoint, looks
> like we can simply program multiple SIDs in the FIB.
>     2) Seems more complex to me. A priori we need to define a tie-
> breaker based on received MS entries. We seem to all agree that 
> local only mapping must be disregarded/less preferred. According to 
> you, this is the easy part, so looks good.
>    3) Is already specified in the ISIS document: https://tools.ietf.
> org/html/draft-ietf-isis-segment-routing-extensions-04#section-2.4.5
> 
> 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,
> privileged information that may be protected by law;
> 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-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: <[email-masked]>
Date: Thu, 18 Jun 2015 07:29:15 +0000

Hi Stéphane,

> From: [email-masked]> 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."
> 

[Bruno] If transit LSRs install all SIDs, an ingress may use any SID, no? Local decision. 

Bruno

---

From: <[email-masked]>
Date: Fri, 19 Jun 2015 09:17:30 +0000

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-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 18, 2015 09:29
To: LITKOWSKI Stephane SCE/IBNF; Stefano Previdi (sprevidi)
Cc: [email-masked]; [email-masked] list
Subject: Re: [spring] Conflicting MS entries

Hi Stéphane,

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.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 19 Jun 2015 18:18:40 +0000

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 agree that selecting one of the entries is preferable to dropping traffic. 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. 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.

> From: spring [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, June 19, 2015 5:17 AM
> To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
> 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.
> 
> 
> ____________________________________________________________________

---

From: <[email-masked]>
Date: Tue, 23 Jun 2015 13:48:09 +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.
> 
> > 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.
> >
> >
> > [email-masked]

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 23 Jun 2015 20:34:07 +0000

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.  

> Sent: Tuesday, June 23, 2015 9:48 AM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: LITKOWSKI Stephane SCE/IBNF; [email-masked]; [email-masked] list;
> Stefano Previdi (sprevidi)
> > From: Aissaoui, Mustapha (Mustapha)
> > [mailto:mustapha.aissaoui@alcatel-> lucent.com] > Sent: Friday, June
> > 19, 2015 8:19 PM
> >
> > Hi Stephane and Bruno,
> > 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:
> > 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.
> 
> 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
> > > 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.
> > >
> > >
> _____________________________________________________
> 
> 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.

---

From: <[email-masked]>
Date: Wed, 24 Jun 2015 07:37:40 +0000

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
 
> > Cc: LITKOWSKI Stephane SCE/IBNF; [email-masked]; [email-masked]
> > list; Stefano Previdi (sprevidi)
> > > 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.
> > > 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.
> >
> > 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
> > > > > From: [email-masked]> Sent: Thursday, June 18,
> > > > > 2015
> > > > > 9:23 AM
> > > > >
> > > > > Hi Bruno,
> > > > >
> > 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.
> >
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Wed, 24 Jun 2015 13:36:55 +0000

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.

> Sent: Wednesday, June 24, 2015 3:38 AM
> > 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.
> 
> > > > [mailto:mustapha.aissaoui@alcatel-> lucent.com] > Sent: Friday,
> > > > June 19, 2015 8:19 PM
> > > >
> > > > Hi Stephane and Bruno,
> > > 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.
> > > - Stéphane expressed that from an operational point, this may make
> > > things
> > harder.
> > > So, so far, it looks like everyone expressed a preference to use
> > > only one, based on deterministic criteria.
> > >
> > > > 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.
> > >
> > > > 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.
> > > >
> > > > > 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.
> > > > >
> > > > >
> > > 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,

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 30 Jun 2015 18:24:29 +0000

Installing multiple SIDs for the same prefix in the FWD is bit off topic though related to the point being discussed.

Have few questions here to answer the "Conflicting MS Entries"

1. Is it a valid configuration to  provision multiple global prefix SIDs for any prefix  ?
     It seems the consensus here is though one can do this there is no real use case.

2. Is it a valid configuration to host a prefix on two nodes with different global prefix SIDs?
     In the similar lines is it valid a configuration to host multiple MSes and advertise different global SID indices for the same prefix?
    I failed to see any valid use case here too.

3. Is it a valid configuration to host a connected or otherwise route on two nodes with same prefix SID?

To me answer for #1 and #2 is invalid.  
 #3 is valid and intention is to host a multi-homed prefix so that all nodes can
 compute ECMP path or prefer lower cost path to one of the nodes.

I prefer staying out of defining any mechanism  which would be any ways  indeterministic for invalid configurations. 

--
Uma C.

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Wednesday, June 24, 2015 6:37 AM
To: [email-masked]
Cc: LITKOWSKI Stephane SCE/IBNF; [email-masked]; [email-masked] list; Stefano Previdi (sprevidi)
Subject: Re: [spring] Conflicting MS entries

Hi Bruno,

Regards,
Mustapha.

> > [mailto:mustapha.aissaoui@alcatel-
> > lucent.com]
> > 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.
> >
> > > > 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.
> > >
> > > etant susceptibles d'alteration, Orange decline toute 
> > > responsabilite si ce message a ete altere,
> > > privileged information that may be protected by law; they should 
> > > not be distributed, used or copied without authorisation.
> d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>