Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[[e-mail]]

Hi Bruno,

 
> “A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an Outside Router. »
> Agreed (so far)
>  
> “A Level 2 LSP with a source system identifier that is found in the Level 1 LSDB MUST NOT be flooded to an Outside Router.”
> I’m not sure to agree.
> If that LSP carries the Area Proxy TLV, the previous rule is enough.
> If that LSP does not carry the Area Proxy TLV, then no Area Leader advertise the Area Proxy System Identifier Sub-TLV and hence the new Area Proxy is not enabled. In which case I feel that normal IS-IS flooding should occur, and L1-L2 nodes should have their L2 LSP flooded.
> So, I would propose to remove that sentence which doesn’t seem needed.


This was intentional. We are trying to protect against a case where a router boots and has not yet processed its full configuration yet.  It could easily generate an LSP prior to adding the Area Proxy TLV.
This could also happen during the transition to Area Proxy, where an Inside Node has not yet been configured for Area Proxy.

We are trying to prevent flooding of its LSP to the Outside Area because that may confuse other L2 nodes.


> “A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an Outside Router. »
> I think we additionally need that an Area Leader advertise the Area Proxy System Identifier Sub-TLV.


We already say:  

	The Area Leader has several responsibilities.  First, it MUST
       inject the Area Proxy System Identifier into the Level 2
       LSDB. 


> Otherwise, hence the new Area Proxy is not enabled. I which case I feel that normal IS-IS flooding should occur, and L1-L2 nodes should have their L1 & L2 LSP flooded.
> That condition would seem application to the whole section 5.2 or even to the whole section 5



Again, we want to restrict flooding if Area Proxy is configured, even if it’s not fully enabled.  Again, we’re just trying to make the transition as smooth as possible.


Tony