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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
