Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Peter Psenak 

Hi Pushpasis,

On 10/9/15 11:00 , Pushpasis Sarkar wrote:

HI Peter,




On 10/9/15, 10:10 AM, "Peter Psenak"  wrote:


Hi Pushpasis,

On 10/8/15 18:41 , Pushpasis Sarkar wrote:

Hi Peter,




On 10/8/15, 6:03 PM, "Peter Psenak"  wrote:


how do you envision to find out the node originating a prefix in case of
inter-area prefixe?

[Pushpasis] The ABR on the originating area/level should be able to detect the 
anomaly like other nodes in the same area/level and block re-advertisement.


Node N1 in area 1 advertises prefix P1 with SID X. ABR1 advertises P1 to
area 0.
Node N2 in area 2 advertises prefix P2 with SID X, ABR2 advertises P2 to
area 0.

Node 3 in area 0 get these two prefixes P1 and P2 from two different
ABRs. How does it know that the originators for P1 and P2 are different?
Do you expect the ABR1 and ABR2 to detect the collision and withdraw SID
advertisement to area 0? If yes, that may become source of all sorts of
problems.

[Pushpasis] Nodes in area 0 can see that for the same prefix there are two 
prefix-sid advertisements from ABR1 and ABR2 but another advertisement (not 
re-advertisement) from Node 3.


there is no advertisement from Node 3 in this case. Node 3 is an 
internal router in area 0 (non-ABR). How does node 3 figures out if the 
prefixes P1 and P2 are sourced by the same node or not? Unless you carry 
the originator-id with each prefix, I don't see how you can do that.


thanks,
Peter


They should then not program a IP->MPLS or MPLS->MPLS route in the FIB and 
raise a syslog. I am not proposing a withdraw of the prefix-sid subtlv. The syslog 
should notify the operator of the misconfiguration scenario.

Thanks
-Pushpasis


thanks,
Peter



Thanks
-Pushpasis





___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Pushpasis Sarkar 
HI Peter,




On 10/9/15, 10:10 AM, "Peter Psenak"  wrote:

>Hi Pushpasis,
>
>On 10/8/15 18:41 , Pushpasis Sarkar wrote:
>> Hi Peter,
>>
>>
>>
>>
>> On 10/8/15, 6:03 PM, "Peter Psenak"  wrote:
>>
>>> how do you envision to find out the node originating a prefix in case of
>>> inter-area prefixe?
>> [Pushpasis] The ABR on the originating area/level should be able to detect 
>> the anomaly like other nodes in the same area/level and block 
>> re-advertisement.
>
>Node N1 in area 1 advertises prefix P1 with SID X. ABR1 advertises P1 to 
>area 0.
>Node N2 in area 2 advertises prefix P2 with SID X, ABR2 advertises P2 to 
>area 0.
>
>Node 3 in area 0 get these two prefixes P1 and P2 from two different 
>ABRs. How does it know that the originators for P1 and P2 are different? 
>Do you expect the ABR1 and ABR2 to detect the collision and withdraw SID 
>advertisement to area 0? If yes, that may become source of all sorts of 
>problems.
[Pushpasis] Nodes in area 0 can see that for the same prefix there are two 
prefix-sid advertisements from ABR1 and ABR2 but another advertisement (not 
re-advertisement) from Node 3. They should then not program a IP->MPLS or 
MPLS->MPLS route in the FIB and raise a syslog. I am not proposing a withdraw 
of the prefix-sid subtlv. The syslog should notify the operator of the 
misconfiguration scenario.

Thanks
-Pushpasis
>
>thanks,
>Peter
>
>>
>> Thanks
>> -Pushpasis
>>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Peter Psenak 

Hi Pushpasis,

On 10/8/15 18:41 , Pushpasis Sarkar wrote:

Hi Peter,




On 10/8/15, 6:03 PM, "Peter Psenak"  wrote:


how do you envision to find out the node originating a prefix in case of
inter-area prefixe?

[Pushpasis] The ABR on the originating area/level should be able to detect the 
anomaly like other nodes in the same area/level and block re-advertisement.


Node N1 in area 1 advertises prefix P1 with SID X. ABR1 advertises P1 to 
area 0.
Node N2 in area 2 advertises prefix P2 with SID X, ABR2 advertises P2 to 
area 0.


Node 3 in area 0 get these two prefixes P1 and P2 from two different 
ABRs. How does it know that the originators for P1 and P2 are different? 
Do you expect the ABR1 and ABR2 to detect the collision and withdraw SID 
advertisement to area 0? If yes, that may become source of all sorts of 
problems.


thanks,
Peter



Thanks
-Pushpasis



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Pushpasis Sarkar 
Some corrections inline




On 10/8/15, 9:59 PM, "Isis-wg on behalf of Pushpasis Sarkar" 
 wrote:

>Hi Les,
>
>
>
>On 10/8/15, 8:51 PM, "Les Ginsberg (ginsberg)"  wrote:
>
>>Pushpasis -
>>
>>Not all conflicts are intra-area - so your response does not cover all cases.
>[Pushpasis] I did not get the above statement. But essentially I meant that in 
>a given area if the same index is originated (and not 
>re-advertise/re-originated) by multiple nodes, the ABRs in that node should 
>not propagate the prefix-sid-tlvs for that prefix to other area.. 
>
>>
>>In addition, your proposal introduces some new problem areas. Do we leak the 
>>prefix but remove the conflicting SID info or stop leaking the prefix 
>>entirely?
>[Pushpasis] Prefix should still be re-advertised, but without the 
>prefix-sid-subtlv. So you stop the SR-reachability without affecting the 
>native IP-reachability.
>
>Thanks
>-Pushpasis
>>
>>If you think about these issues I believe the advantage of Stefano's proposal 
>>becomes clear.
>>
>> Les
>___
>Isis-wg mailing list
>isis...@ietf.org
>https://www.ietf.org/mailman/listinfo/isis-wg
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Pushpasis Sarkar 
Hi Les,



On 10/8/15, 8:51 PM, "Les Ginsberg (ginsberg)"  wrote:

>Pushpasis -
>
>Not all conflicts are intra-area - so your response does not cover all cases.
[Pushpasis] I did not get the above statement. But essentially I meant that in 
a given area if the same index is originated (and not 
re-advertise/re-originated), the ABRs in that node should not propagate the 
prefix-sid-tlvs for that prefix to other area.. 

>
>In addition, your proposal introduces some new problem areas. Do we leak the 
>prefix but remove the conflicting SID info or stop leaking the prefix entirely?
[Pushpasis] Prefix should still be re-advertised, but without the 
prefix-sid-subtlv. So you stop the SR-reachability without affecting the native 
IP-reachability.

Thanks
-Pushpasis
>
>If you think about these issues I believe the advantage of Stefano's proposal 
>becomes clear.
>
> Les
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Pushpasis Sarkar 
Hi Ahmed,




On 10/8/15, 8:18 PM, "Ahmed Bashandy (bashandy)"  wrote:

>
>if I understand you reply to Peter correctly, does this means that 
>multi-prefix SID should not be leaked outside its originating area?
[Pushpasis] For backward-compatibility with classic IGP, prefix should be 
re-advertised.. But prefix-sid sub-tlv should not be propagated… 

Thanks
-Pushpasis

>
>Ahmed
>
>
>On 10/8/2015 6:11 AM, Pushpasis Sarkar wrote:
>> Hi Peter,
>>
>>
>>
>>
>> On 10/8/15, 6:03 PM, "Peter Psenak"  wrote:
>>
>>> how do you envision to find out the node originating a prefix in case of
>>> inter-area prefixe?
>> [Pushpasis] The ABR on the originating area/level should be able to detect 
>> the anomaly like other nodes in the same area/level and block 
>> re-advertisement.
>>
>> Thanks
>> -Pushpasis
>> ___
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Les Ginsberg (ginsberg) 
Pushpasis -

Not all conflicts are intra-area - so your response does not cover all cases.

In addition, your proposal introduces some new problem areas. Do we leak the 
prefix but remove the conflicting SID info or stop leaking the prefix entirely?

If you think about these issues I believe the advantage of Stefano's proposal 
becomes clear.

 Les

> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pushpasis Sarkar
> Sent: Thursday, October 08, 2015 6:12 AM
> To: Peter Psenak (ppsenak); Stefano Previdi (sprevidi)
> Cc: Hannes Gredler; spring@ietf.org; Robert Raszuk; isis...@ietf.org list;
> Clarence Filsfils (cfilsfil)
> Subject: Re: [spring] [Isis-wg] Handling same SID mapped to different
> prefixes and vice versa cases
> 
> Hi Peter,
> 
> 
> 
> 
> On 10/8/15, 6:03 PM, "Peter Psenak"  wrote:
> 
> >how do you envision to find out the node originating a prefix in case
> >of inter-area prefixe?
> [Pushpasis] The ABR on the originating area/level should be able to detect
> the anomaly like other nodes in the same area/level and block re-
> advertisement.
> 
> Thanks
> -Pushpasis
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Ahmed Bashandy (bashandy) 


if I understand you reply to Peter correctly, does this means that 
multi-prefix SID should not be leaked outside its originating area?


Ahmed


On 10/8/2015 6:11 AM, Pushpasis Sarkar wrote:

Hi Peter,




On 10/8/15, 6:03 PM, "Peter Psenak"  wrote:


how do you envision to find out the node originating a prefix in case of
inter-area prefixe?

[Pushpasis] The ABR on the originating area/level should be able to detect the 
anomaly like other nodes in the same area/level and block re-advertisement.

Thanks
-Pushpasis
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Pushpasis Sarkar 
Hi Peter,




On 10/8/15, 6:03 PM, "Peter Psenak"  wrote:

>how do you envision to find out the node originating a prefix in case of 
>inter-area prefixe?
[Pushpasis] The ABR on the originating area/level should be able to detect the 
anomaly like other nodes in the same area/level and block re-advertisement. 

Thanks
-Pushpasis
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

2015-10-08 Thread Peter Psenak 

Hi Pushpasis,

On 10/7/15 19:51 , Pushpasis Sarkar wrote:

HI Stefano,

From: "Stefano Previdi (sprevidi)"
Date: Wednesday, October 7, 2015 at 7:31 PM
To: Pushpasis Sarkar
Cc: Robert Raszuk, Hannes Gredler, "spring@ietf.org
", Isis-wg, "Clarence Filsfils (cfilsfil)"
Subject: Re: [spring] [Isis-wg] Handling same SID mapped to different
prefixes and vice versa cases

You decide on a per-prefix base,  which node-sid of the originator you
want to use (if any).
*[Pushpasis] The default policy for deciding the sid to use should be
the sid associated with prefix in the advertisement. Off course that can
be overridden with some local policy but that is upto the
implementation. The default behavior should be to use the sid associated
with the prefix originally. With that default behavior the ingress
should be able to use the same tunnel for more than one prefixes all
originated from the same node.


how do you envision to find out the node originating a prefix in case of 
inter-area prefixe?


thanks,
Peter


Which means that the originator should be
able associate the same node-sid with more than one prefixes originated
locally on that node.*
*
*
*The question I have is what is the problem if we associate the same
index for multiple prefix as long as those prefixes are all originated
on the same node? I don’t see a issue yet. If you can pick an example
and illustrate the issue you have in mind, perhaps it will help me to
get convinced as well..*
*
*
*Thanks*
*-Pushpasis*



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring