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

[[e-mail]]

Les,

> As per the draft:
>  
> Area Proxy TLV is advertised by IERs in their L2 LSP. 
> Area Proxy TLV is NOT advertised in the Proxy LSP.
> So how do the OERs become aware of the 
>  
> “prefix and  SID that represents the entirety of the Inside Area to the Outside  Area”
>  
> ???
>  
> I assume that they learn this because the Proxy LSP (at least) contains a Prefix Reachability TLV with the same prefix/SID that was advertised in the Area Proxy TLV.
> Is this correct? If not, please correct me.


That’s correct.  If this isn’t crystal clear from the draft, please work with me to get it clarified to your satisfaction.


> Also explain why it is necessary for something other than a prefix reachability advertisement to cause an entry to be created in forwarding for a prefix – and ONLY when received in an L2 LSP?
> This is unprecedented.



It is unprecedented because there we are proposing something unprecedented.  I repeat: "There is no other mechanism whereby system A can advertise a prefix SID to a number of other systems and have them install receive/POP forwarding entries.”

It is NOT creating forwarding TO a prefix.  It’s reception.


> If I am right, you then have  multiple TLVs which advertise duplicate advertisements – even if not in the same LSP - which exposes you to the problems I mentioned.
> My goal is to have one – and only one – advertisement which creates forwarding state.


Well, I’m sorry, but your goal is unachievable.  The Proxy LSP is only relevant outside of the area.  The Inner Node LSPs aren’t circulated outside of the area.


> My second goal is not to invent a new SID type/advertisement when the object associated with it (a prefix) already has a defined SID type.


Which is why we’re using the Prefix SID.

 
> What I object to – and am concerned about – is that you seem to invent your version of SR for Area Proxy even when you use the same object (a prefix) that SR already supports.


Again, SR does not support the semantics that we require. 


> As you know, I was prepared to support a new type of SID when you actually were defining a new object type. The fact that you decided NOT to invent a new object type is fine with me – but please do not claim that you need a new SID type when you don’t.


I’m sorry that you still don’t understand.  We do need something different.

Tony