Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[tony . li]

Hi Hannes,

Thanks for your comments.  We will propose an alternate encoding.

Tony


> On Jun 25, 2020, at 10:47 AM, Hannes Gredler  wrote:
> 
> 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

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[Hannes Gredler]

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

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[tony . li]

Chris,

Thank you for your comments.  We will figure out how we would like to proceed.

Thanks,
Tony


> On Jun 24, 2020, at 5:17 PM, Christian Hopps  wrote:
> 
> 
> 
>> On Jun 21, 2020, at 12:50 PM, 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?
> 
> [Designated Expert hat]
> 
> I agree that we should try and reduce the number of top-level TLV allocations 
> being made here.
> 
> [WG member hat]
> 
> I think using router capabilities to eliminate the Area Proxy TLV is one 
> choice, and you shouldn't be afraid of storing some capability related extra 
> octets in it, plenty of other users do this already.
> 
> However, if you're still going to need a top-level TLV for "Inside Node" 
> (perhaps b/c we fear using a Router Capability TLVs in pseudo-node?), then 
> why not create a single top level "Area Proxy TLV" for all Area Proxy uses 
> (i.e., make the current "Area Proxy TLV" and "Inside Node TLV" sub-TLVs of 
> that top-level container) instead?
> 
> Thanks,
> Chris.
> [see above for hats]
> 
>> 
>> 
>>> 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