Hi Tony,

I do share Les’ concerns on burning top-level 8-bit code point space at this 
point.

At this point it is not me to judge wether CAP TLV or GENAPP TLV or something 
else should be a more appropriate place.
Please let's have a WG discussion on this.

Thanks,

/hannes

> On 21.06.2020, at 18:50, tony...@tony.li wrote:
> 
> 
> Les,
> 
>> We don’t have to resolve this now.
>> One of my motivations for sending this was related to Early Allocation of 
>> code points. Since you have already asked once, I am assuming that if WG 
>> adoption is achieved it will be swiftly followed by an early allocation 
>> request – and as one of the Designated Experts I wanted to share my concerns 
>> sooner rather than later.
> 
> 
> I appreciate that.  Do others share Les’ perspective on the relative 
> tradeoffs?  Especially our other Desginated Experts?
> 
> 
>> Would this argue for advertising “this is a boundary circuit” in pseudo-node 
>> LSPs for boundary circuits rather than advertising “inside” on all inside 
>> pseudo-nodes?
>>   
>> You could do it that way.  It inverts the semantics and inverts the 
>> deployment.  Logically, it should have the same effect.  However, it then is 
>> seen by outside nodes.  Since they need not support Area Proxy, this seemed 
>> like a riskier approach, thus we opted for marking inside pseudonodes.
>>  
>> [Les:] My point was largely motivated by the statement in the draft:
>>  
>> “Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
>>    mode) with multiple Inside Edge Routers on them are not supported.”
>>  
>> So it seems advantageous to be able to prevent this from happening – which 
>> requires some signaling on the circuit in question.
> 
> 
> 
> I think that the case that you’re concerned about is already easily detected. 
>  Recall that an Inside Edge router will generate IIH’s onto a boundary 
> circuit using the Proxy system ID.  Thus, if an Inside Edge router receives 
> an IIH with a source address of it’s own proxy system id, then it has 
> encountered this issue.
> 
> Tony
> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to