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

2020-07-03 Thread Christian Hopps 


> On Jun 30, 2020, at 2:33 AM, tony...@tony.li wrote:
> 
> 
> Hi all,
> 
> The authors are on-board with this round of suggestions from Les.  Could I 
> get a review by one more of our Designated Experts before we update the draft?

So:

- Top Level Area Proxy TLV
  - can be used to communicate area proxy capability
  - can be used to communicate inside node trait
  - can be used to communicate area proxy system id
- Re-use existing SPRING TLVs to communicate Area SID

and the early request would be for a single top-level area proxy TLV code-point?

If so, then it aligns with my earlier [wg hat] suggestion as well, and so looks 
good to me [de hat]. :)

Thanks,
Chris.
[DE/WG member hats]

> 
> Thanks,
> Tony
> 
> 
>> On Jun 29, 2020, at 3:07 PM, Les Ginsberg (ginsberg)  
>> wrote:
>> 
>> Tony –
>> 
>> Inline.
>> 
>> From: Tony Li  On Behalf Of tony...@tony.li
>> Sent: Monday, June 29, 2020 2:37 PM
>> To: Les Ginsberg (ginsberg) 
>> Cc: Hannes Gredler ; 
>> draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
>> Subject: Re: [Lsr] Comments on Requested Codepoints for 
>> draft-li-lsr-isis-area-proxy
>> 
>> 
>> 
>> Hi Les,
>> 
>> 
>> 
>> On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg)  
>> wrote:
>> 
>> Tony –
>> 
>> OLD:
>> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>> 
>> 2)Inside Node TLV - Top level TLV
>> 
>> 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>>Sub-TLV Area Proxy System ID
>>Sub-TLV Area Segment SID
>> 
>> 4)Area Segment SID - Top Level TLV
>> 
>> NEW: (Please check my interpretation)
>> 
>> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>> 
>> 2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>>Sub-TLV Area Proxy System ID
>>Sub-TLV Area Segment SID
>>Sub-TLV Inside Node ???
>> 
>> 3)Area Segment SID - Top Level TLV
>> 
>> Am I correct so far??
>> 
>> 
>> Yes, exactly.  Inside node would be a sub-TLV or a flag, TBD.
>> 
>> 
>> If so, a couple more comments/suggestions:
>> 
>> a)Could the Area Proxy TLV become a bit more generic and allow advertisement 
>> of the capability (implied by presence of the TLV)?
>> If  so, the Router Capability sub-TLV could go away.
>> 
>> 
>> Speaking just for myself, ok, that seems reasonable and doable.
>> 
>> 
>> 
>> b)If the Area Segment SID is (as you suggest) a generic thing not specific 
>> to Area Proxy, then I would point you to 
>> https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1
>> 
>> 
>> ?  Your pointer is to the flags field of the SID/Label Binding TLV.
>> 
>> [Les:] Yes – as the suggestion would be to add another flag definition.
>> 
>> 
>> This allows SIDs to be advertised in the SID Binding TLV for a special 
>> purpose (see the Mirror SID). One could imagine another flag bit to indicate 
>> this is an Area SID.
>> 
>> 
>> You’re suggesting a bit in the flags, the range would be unused, and a 
>> prefix length of 0? Then the actual SID would be in the SID/Label sub-TLV?
>> 
>> [Les:]Range could be specified as ignored in this case. Prefix length would 
>> be 0.
>> The SID would be – as you say – advertised in the SID/Label sub-TLV – as 
>> with all other SIDs.
>> 
>> 
>> I think this would need to be vetted with SR  folks
>> 
>> 
>> That will happen, regardless of how we proceed.
>> 
>> 
>> 
>> – but I would like to avoid advertising a SID in a way different from all 
>> other SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – 
>> whether it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), 
>> or Binding SID (Mirror SID).
>> 
>> 
>> We were trying to extend the current design consistently with existing SIDs. 
>>  As the Prefix SID and Adjacency SID were top level, it made sense to 
>> continue that approach.  The approach of the Binding SID TLV would seem to 
>> mix all semantics into one encoding and seems inconsistent and complicated 
>> with respect to the other SIDs.  If this was the intent, shouldn’t prefix 
>> and adjacency SIDs be encoded in this TLV as well?
>> [Les:] Prefix/adjacency SIDs are sub-TLVs of TLVs 135 and 22 respectively.
>> 
>> There’s only three available bits (plus one octet) here.  Aren’t we 
>> concerned about running out of bits if we go this direction?
>> [Les:] I am not. It is a question of whether SR sees this as a useful type 
>> of SID. If so, it merits a bit.
>> 
>>Les
>> 
>> Tony
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr



signature.asc
Description: Message signed with OpenPGP
___
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

2020-06-30 Thread tony . li 

Hi all,

The authors are on-board with this round of suggestions from Les.  Could I get 
a review by one more of our Designated Experts before we update the draft?

Thanks,
Tony


> On Jun 29, 2020, at 3:07 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Tony –
>  
> Inline.
>  
> From: Tony Li mailto:tony1ath...@gmail.com>> On 
> Behalf Of tony...@tony.li <mailto:tony...@tony.li>
> Sent: Monday, June 29, 2020 2:37 PM
> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
> Cc: Hannes Gredler mailto:han...@gredler.at>>; 
> draft-li-lsr-isis-area-proxy.auth...@ietf.org 
> <mailto:draft-li-lsr-isis-area-proxy.auth...@ietf.org>; lsr@ietf.org 
> <mailto:lsr@ietf.org>
> Subject: Re: [Lsr] Comments on Requested Codepoints for 
> draft-li-lsr-isis-area-proxy
>  
>  
>  
> Hi Les,
>  
> 
> 
> On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg)  <mailto:ginsb...@cisco.com>> wrote:
>  
> Tony –
>  
> OLD:
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Inside Node TLV - Top level TLV
>  
> 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>Sub-TLV Area Proxy System ID
>Sub-TLV Area Segment SID
>  
> 4)Area Segment SID - Top Level TLV
>  
> NEW: (Please check my interpretation)
>  
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>Sub-TLV Area Proxy System ID
>Sub-TLV Area Segment SID
>Sub-TLV Inside Node ???
>  
> 3)Area Segment SID - Top Level TLV
>  
> Am I correct so far??
>  
>  
> Yes, exactly.  Inside node would be a sub-TLV or a flag, TBD.
>  
>  
> If so, a couple more comments/suggestions:
>  
> a)Could the Area Proxy TLV become a bit more generic and allow advertisement 
> of the capability (implied by presence of the TLV)?
> If  so, the Router Capability sub-TLV could go away.
>  
>  
> Speaking just for myself, ok, that seems reasonable and doable.
>  
> 
> 
> b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
> Area Proxy, then I would point you to 
> https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1 
> <https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1>
>  
>  
> ?  Your pointer is to the flags field of the SID/Label Binding TLV.
>  
> [Les:] Yes – as the suggestion would be to add another flag definition.
> 
> 
> This allows SIDs to be advertised in the SID Binding TLV for a special 
> purpose (see the Mirror SID). One could imagine another flag bit to indicate 
> this is an Area SID.
>  
>  
> You’re suggesting a bit in the flags, the range would be unused, and a prefix 
> length of 0? Then the actual SID would be in the SID/Label sub-TLV?
>  
> [Les:]Range could be specified as ignored in this case. Prefix length would 
> be 0.
> The SID would be – as you say – advertised in the SID/Label sub-TLV – as with 
> all other SIDs.
> 
> 
> I think this would need to be vetted with SR  folks 
>  
>  
> That will happen, regardless of how we proceed.
>  
> 
> 
> – but I would like to avoid advertising a SID in a way different from all 
> other SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – 
> whether it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), 
> or Binding SID (Mirror SID).
>  
>  
> We were trying to extend the current design consistently with existing SIDs.  
> As the Prefix SID and Adjacency SID were top level, it made sense to continue 
> that approach.  The approach of the Binding SID TLV would seem to mix all 
> semantics into one encoding and seems inconsistent and complicated with 
> respect to the other SIDs.  If this was the intent, shouldn’t prefix and 
> adjacency SIDs be encoded in this TLV as well?
> [Les:] Prefix/adjacency SIDs are sub-TLVs of TLVs 135 and 22 respectively.
>  
> There’s only three available bits (plus one octet) here.  Aren’t we concerned 
> about running out of bits if we go this direction?
> [Les:] I am not. It is a question of whether SR sees this as a useful type of 
> SID. If so, it merits a bit.
>  
>Les
>  
> Tony

___
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

2020-06-29 Thread Les Ginsberg (ginsberg) 
Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Monday, June 29, 2020 2:37 PM
To: Les Ginsberg (ginsberg) 
Cc: Hannes Gredler ; 
draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Comments on Requested Codepoints for 
draft-li-lsr-isis-area-proxy



Hi Les,



On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Tony –

OLD:
1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Inside Node TLV - Top level TLV

3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID

4)Area Segment SID - Top Level TLV

NEW: (Please check my interpretation)

1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID
   Sub-TLV Inside Node ???

3)Area Segment SID - Top Level TLV

Am I correct so far??


Yes, exactly.  Inside node would be a sub-TLV or a flag, TBD.


If so, a couple more comments/suggestions:

a)Could the Area Proxy TLV become a bit more generic and allow advertisement of 
the capability (implied by presence of the TLV)?
If  so, the Router Capability sub-TLV could go away.


Speaking just for myself, ok, that seems reasonable and doable.



b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
Area Proxy, then I would point you to 
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1


?  Your pointer is to the flags field of the SID/Label Binding TLV.

[Les:] Yes – as the suggestion would be to add another flag definition.


This allows SIDs to be advertised in the SID Binding TLV for a special purpose 
(see the Mirror SID). One could imagine another flag bit to indicate this is an 
Area SID.


You’re suggesting a bit in the flags, the range would be unused, and a prefix 
length of 0? Then the actual SID would be in the SID/Label sub-TLV?

[Les:]Range could be specified as ignored in this case. Prefix length would be 
0.
The SID would be – as you say – advertised in the SID/Label sub-TLV – as with 
all other SIDs.


I think this would need to be vetted with SR  folks


That will happen, regardless of how we proceed.



– but I would like to avoid advertising a SID in a way different from all other 
SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – whether 
it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), or Binding 
SID (Mirror SID).


We were trying to extend the current design consistently with existing SIDs.  
As the Prefix SID and Adjacency SID were top level, it made sense to continue 
that approach.  The approach of the Binding SID TLV would seem to mix all 
semantics into one encoding and seems inconsistent and complicated with respect 
to the other SIDs.  If this was the intent, shouldn’t prefix and adjacency SIDs 
be encoded in this TLV as well?
[Les:] Prefix/adjacency SIDs are sub-TLVs of TLVs 135 and 22 respectively.

There’s only three available bits (plus one octet) here.  Aren’t we concerned 
about running out of bits if we go this direction?
[Les:] I am not. It is a question of whether SR sees this as a useful type of 
SID. If so, it merits a bit.

   Les

Tony

___
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

2020-06-29 Thread tony . li 


Hi Les,


> On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Tony –
>  
> OLD:
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Inside Node TLV - Top level TLV
>  
> 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>Sub-TLV Area Proxy System ID
>Sub-TLV Area Segment SID
>  
> 4)Area Segment SID - Top Level TLV
>  
> NEW: (Please check my interpretation)
>  
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>Sub-TLV Area Proxy System ID
>Sub-TLV Area Segment SID
>Sub-TLV Inside Node ???
>  
> 3)Area Segment SID - Top Level TLV
>  
> Am I correct so far??


Yes, exactly.  Inside node would be a sub-TLV or a flag, TBD.

 
> If so, a couple more comments/suggestions:
>  
> a)Could the Area Proxy TLV become a bit more generic and allow advertisement 
> of the capability (implied by presence of the TLV)?
> If  so, the Router Capability sub-TLV could go away.


Speaking just for myself, ok, that seems reasonable and doable.


> b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
> Area Proxy, then I would point you to 
> https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1 
> 

?  Your pointer is to the flags field of the SID/Label Binding TLV.


> This allows SIDs to be advertised in the SID Binding TLV for a special 
> purpose (see the Mirror SID). One could imagine another flag bit to indicate 
> this is an Area SID.


You’re suggesting a bit in the flags, the range would be unused, and a prefix 
length of 0? Then the actual SID would be in the SID/Label sub-TLV?


> I think this would need to be vetted with SR  folks


That will happen, regardless of how we proceed.


> – but I would like to avoid advertising a SID in a way different from all 
> other SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – 
> whether it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), 
> or Binding SID (Mirror SID).


We were trying to extend the current design consistently with existing SIDs.  
As the Prefix SID and Adjacency SID were top level, it made sense to continue 
that approach.  The approach of the Binding SID TLV would seem to mix all 
semantics into one encoding and seems inconsistent and complicated with respect 
to the other SIDs.  If this was the intent, shouldn’t prefix and adjacency SIDs 
be encoded in this TLV as well?

There’s only three available bits (plus one octet) here.  Aren’t we concerned 
about running out of bits if we go this direction?

Tony

___
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

2020-06-29 Thread Les Ginsberg (ginsberg) 
Tony –

OLD:
1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Inside Node TLV - Top level TLV

3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID

4)Area Segment SID - Top Level TLV

NEW: (Please check my interpretation)

1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID
   Sub-TLV Inside Node ???

3)Area Segment SID - Top Level TLV

Am I correct so far??

If so, a couple more comments/suggestions:

a)Could the Area Proxy TLV become a bit more generic and allow advertisement of 
the capability (implied by presence of the TLV)?
If  so, the Router Capability sub-TLV could go away.

b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
Area Proxy, then I would point you to 
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1
This allows SIDs to be advertised in the SID Binding TLV for a special purpose 
(see the Mirror SID). One could imagine another flag bit to indicate this is an 
Area SID.
I think this would need to be vetted with SR  folks – but I would like to avoid 
advertising a SID in a way different from all other SIDs i.e., SIDs currently 
are always a sub-TLV of some top level TLV – whether it be Prefix Reachability 
(Prefix-SID), IS Neighbor (Adjacency SID), or Binding SID (Mirror SID).

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Monday, June 29, 2020 12:52 PM
To: Hannes Gredler 
Cc: Les Ginsberg (ginsberg) ; 
draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] Comments on Requested Codepoints for 
draft-li-lsr-isis-area-proxy



Hi,

The authors have conferred and we would like to propose the following changes:

- The semantics of the Inside Node TLV will be folded into the Area Proxy TLV.

- The Area Proxy TLV will have its scope expanded to include pseudonodes.

- No change to the Area Segment SID TLV encoding.

Comments?   Especially from our Designated Experts?

Regards,
Sarah, Vivek, Gyan, and Tony



On Jun 25, 2020, at 12:04 PM, tony...@tony.li<mailto:tony...@tony.li> wrote:


Hi Hannes,

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

Tony



On Jun 25, 2020, at 10:47 AM, Hannes Gredler 
mailto:han...@gredler.at>> 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<mailto: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<mailto: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

2020-06-29 Thread tony . li 


Hi,

The authors have conferred and we would like to propose the following changes:

- The semantics of the Inside Node TLV will be folded into the Area Proxy TLV.

- The Area Proxy TLV will have its scope expanded to include pseudonodes.

- No change to the Area Segment SID TLV encoding.

Comments?   Especially from our Designated Experts?

Regards,
Sarah, Vivek, Gyan, and Tony


> On Jun 25, 2020, at 12:04 PM, tony...@tony.li wrote:
> 
> 
> 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

2020-06-25 Thread 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

2020-06-25 Thread 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

2020-06-25 Thread 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

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

2020-06-24 Thread Christian Hopps 


> 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

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

2020-06-21 Thread tony . li 

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

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

2020-06-21 Thread Les Ginsberg (ginsberg) 
Tony –

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.

A few more responses inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Saturday, June 20, 2020 5:13 PM
To: Les Ginsberg (ginsberg) 
Cc: draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy


Hi Les,

Putting the Inside Node TLV aside for the moment, it would seem to me to be 
advantageous (in a modest way) to have all information relating to Area Proxy 
contained in one advertisement. Using Router Capabilities TLV would accomplish 
that.


I agree that the information should be contained, this is why we opted to put 
it all into one top level TLV.  Recall that only the Area Leader is advertising 
the Area Proxy TLV, while all inside nodes need the capability.

[Les:] My proposal does not alter what information is sent by Area 
leaders/non-Area leaders – just the container in which the information appears.


Your concern about “burdening” the Router Capabilities TLV seems unwarranted.


Given that we have 64k top level code points, I’m equally confused about your 
concern.

[Les:] Today, we only have 255 top level codepoints.
64K codepoints will only become available when the industry moves to RFC 7356 
based implementations and includes the 16 bit TLV Type/Length option.
While I would obviously like to see this happen, as it isn’t backwards 
compatible I expect we are still some years away from a “tectonic shift”.
And your draft does not propose moving to RFC 7356 as part of the feature (and 
I am not suggesting that it should).

At least part of the reason we still have sufficient available top level code 
points is that we do our collective best to use them judiciously.


Multiple Router Capability TLVs are allowed (indeed even required to support 
different flooding scopes) – so TLV space is not limited.


I expect that we will have numerous bug reports when we start to cross the TLV 
boundary.  I’m not in favor of pushing this.

 [Les:] We already enough info to advertise that one Router Capability TLV is 
not enough. Implementations that cannot handle multiple Router Capability TLVs 
are already busted.
Area Proxy by itself won’t force this to be exposed.

Returning to Inside Node TLV, I share your concern about advertising Router 
Capabilities TLV in pseudo-node LSP. But what does it mean to advertise the 
Inside Node TLV in a pseudo-node LSP?


It’s a clear indication that the pseudonode is intended to be inside.



Presumably you need some capability indicator because even on boundary circuits 
the DIS will use the native systemid rather than the proxy systemid and 
therefore you cannot tell based on pseudonode-id alone what type of circuit 
this is.


Correct. The DIS would have a very difficult time using the proxy systemid and 
assigning a unique circuit id for the pseduonode.  Some other system on the 
other side of the area could be making exactly the same choice, leading to a 
collision.  Thus, it seems simpler to use the native system id and explicitly 
signal that the pseudonode is inside.  I’ve become a pretty big fan of explicit 
signaling, as it’s more robust.

[Les:] Yes, I understand  and agree with your choice. There is no good way to 
manage the pseudo-node ID space in a distributed manner.


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.


And do you need the “boundary circuit” indication in L2 IIHs (and perhaps P2P 
IIH as well??) as protection against improperly forming adjacencies on boundary 
circuits?


Not required if there is consistent configuration.  All inside nodes will be 
using the proxy system ID in their IIH.  If a node is inconsistently 
configured, then it is difficult to prevent at least one side from trying to 
form the adjacency.

[Les:] Yes – the key point here is “consistent configuration”. It seems useful 
to be able to detect/report mismatched configurations

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

2020-06-20 Thread tony . li 

Hi Les,

> Putting the Inside Node TLV aside for the moment, it would seem to me to be 
> advantageous (in a modest way) to have all information relating to Area Proxy 
> contained in one advertisement. Using Router Capabilities TLV would 
> accomplish that.


I agree that the information should be contained, this is why we opted to put 
it all into one top level TLV.  Recall that only the Area Leader is advertising 
the Area Proxy TLV, while all inside nodes need the capability.


> Your concern about “burdening” the Router Capabilities TLV seems unwarranted.


Given that we have 64k top level code points, I’m equally confused about your 
concern.


> Multiple Router Capability TLVs are allowed (indeed even required to support 
> different flooding scopes) – so TLV space is not limited.


I expect that we will have numerous bug reports when we start to cross the TLV 
boundary.  I’m not in favor of pushing this.

 
> Returning to Inside Node TLV, I share your concern about advertising Router 
> Capabilities TLV in pseudo-node LSP. But what does it mean to advertise the 
> Inside Node TLV in a pseudo-node LSP?


It’s a clear indication that the pseudonode is intended to be inside.


> Presumably you need some capability indicator because even on boundary 
> circuits the DIS will use the native systemid rather than the proxy systemid 
> and therefore you cannot tell based on pseudonode-id alone what type of 
> circuit this is.


Correct. The DIS would have a very difficult time using the proxy systemid and 
assigning a unique circuit id for the pseduonode.  Some other system on the 
other side of the area could be making exactly the same choice, leading to a 
collision.  Thus, it seems simpler to use the native system id and explicitly 
signal that the pseudonode is inside.  I’ve become a pretty big fan of explicit 
signaling, as it’s more robust.


> 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.


> And do you need the “boundary circuit” indication in L2 IIHs (and perhaps P2P 
> IIH as well??) as protection against improperly forming adjacencies on 
> boundary circuits?


Not required if there is consistent configuration.  All inside nodes will be 
using the proxy system ID in their IIH.  If a node is inconsistently 
configured, then it is difficult to prevent at least one side from trying to 
form the adjacency.


> Regarding the Area SID advertisement, I take the point that this concept 
> might be useful more generically, but as it is key to have the correct scope 
> for the SID, it is hard to see how the advertisement could be used apart from 
> the context (Area Proxy in this case). So advertising it separately doesn’t 
> seem useful.


To me, it seems like it is a useful anycast SID anytime there is hierarchy 
present.  It seems somewhat useful to be able to create paths that say things a 
bit more abstractly: Take the path from San Francisco, through Los Angeles, 
Dallas, St. Louis, and then Atlanta to get to Washington. This would allow 
higher level TE without worrying about more specific details. This also opens 
up the possibility of hierarhcical TE, which we may wish to explore for the 
sake of scalability.

 
> Regarding consistent SRGBs, you might find 
> https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/ 
>  
> worth reading as something attempting to address a similar problem. It isn’t 
> easy.


Thank you for the pointer, I will review.

I appreciate your comments.  I wish that they had been much earlier in the 
process.  I will take them much more seriously if and when the document is 
adopted by the WG.

Tony



___
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

2020-06-20 Thread Les Ginsberg (ginsberg) 
Tony –

Thanx for the quick response.

Putting the Inside Node TLV aside for the moment, it would seem to me to be 
advantageous (in a modest way) to have all information relating to Area Proxy 
contained in one advertisement. Using Router Capabilities TLV would accomplish 
that.
Your concern about “burdening” the Router Capabilities TLV seems unwarranted.
Every capability currently defined comes with additional information.
Multiple Router Capability TLVs are allowed (indeed even required to support 
different flooding scopes) – so TLV space is not limited.

Returning to Inside Node TLV, I share your concern about advertising Router 
Capabilities TLV in pseudo-node LSP. But what does it mean to advertise the 
Inside Node TLV in a pseudo-node LSP?
Presumably you need some capability indicator because even on boundary circuits 
the DIS will use the native systemid rather than the proxy systemid and 
therefore you cannot tell based on pseudonode-id alone what type of circuit 
this is.

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?

And do you need the “boundary circuit” indication in L2 IIHs (and perhaps P2P 
IIH as well??) as protection against improperly forming adjacencies on boundary 
circuits?

Regarding the Area SID advertisement, I take the point that this concept might 
be useful more generically, but as it is key to have the correct scope for the 
SID, it is hard to see how the advertisement could be used apart from the 
context (Area Proxy in this case). So advertising it separately doesn’t seem 
useful.

Regarding consistent SRGBs, you might find 
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/ worth 
reading as something attempting to address a similar problem. It isn’t easy.

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Saturday, June 20, 2020 1:41 PM
To: Les Ginsberg (ginsberg) 
Cc: draft-li-lsr-isis-area-proxy.auth...@ietf.org; lsr@ietf.org
Subject: Re: Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy


Hi Les,

Thank you for your comments.  Please see my comments inline.


draft-li-lsr-isis-area-proxy-06  currently proposes the use of one new sub-TLV 
of Router Capabilities TLV and three new top level TLVs


It should probably be noted that the Area Segment SID is somewhat orthogonal to 
the rest of Area Proxy.   It could be conceivably be used without
Area Proxy, or with another solution.

It would not be unreasonable to consider the Area Segment SID to be a proposal 
logically independent of Area Proxy.  Thus, Area Proxy really is requesting two 
new top level TLVs.


1)Area Proxy Router Capability - sub-TLV of Router Capability TLV

2)Inside Node TLV - Top level TLV

3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
   Sub-TLV Area Proxy System ID
   Sub-TLV Area Segment SID

4)Area Segment SID - Top Level TLV


Comments:
This seems unnecessarily profligate in its consumption of top level TLV code 
points – something to which, as a Designated Expert for the IS-IS registries,  
I pay close attention.
I can imagine an alternative encoding which utilizes a single sub-TLV within 
the Router Capabilities TLV:

Area Proxy Router Capability sub-TLV

  Type: TBD
  Length: Variable
  Value: Flags + Optional sub-TLVs

1 octet of Flags:

  0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+
  |I|L|P| RSVD  |
  +-+-+-+-+-+-+-+

I If set indicates Inside Node
L If set indicates capable of performing Area Leader functions
P If set indicates Proxy LSP advertisement
RSVD - for future allocation

Followed by optional sub-sub-TLVs

Sub-sub-TLV Area Proxy System ID
Sub-sub-TLV Area SID (Used only when P bit is set)

Please comment on this alternative.


One of the issues that drove us to introduce the Inside Node TLV was confusion 
about pseudonodes.  How does a node determine whether a pseudonode is Inside or 
Outside?  This is an important at flooding time because if it is Inside, it 
should be flooded externally.  We did not consider putting a router capability 
TLV into a pseudonode and opted for another top level TLV instead.

We chose to make the Area Proxy TLV a top level TLV because we felt that it was 
inappropriate to burden the Router Capabilities TLV with arbitrary amounts of 
additional data. In our humble opinion, the router capabilities TLV should be 
reserved for capabilities.  Yes, it’s true, we could put that data inside of 
the router capabilities TLV, but as we learned a long time ago with GUP, we can 
pretty much put anything anywhere. Just because we can doesn’t mean that we 
should.


Additional Questions:
It is not clear to me why Area SID requires two different advertisements :
1)As a sub-TLV of Area Proxy TLV and
2)As a top Level TLV in the Proxy LSP
Is it because you wanted a unique codepoint for the Proxy LSP advertisements?


We wanted the sub-TLV so that the Area Leader can distribute the value

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

2020-06-20 Thread tony . li 

Hi Les,

Thank you for your comments.  Please see my comments inline.

 
> draft-li-lsr-isis-area-proxy-06  currently proposes the use of one new 
> sub-TLV of Router Capabilities TLV and three new top level TLVs


It should probably be noted that the Area Segment SID is somewhat orthogonal to 
the rest of Area Proxy.   It could be conceivably be used without
Area Proxy, or with another solution.

It would not be unreasonable to consider the Area Segment SID to be a proposal 
logically independent of Area Proxy.  Thus, Area Proxy really is requesting two 
new top level TLVs.
 

> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Inside Node TLV - Top level TLV
>  
> 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>Sub-TLV Area Proxy System ID
>Sub-TLV Area Segment SID
>  
> 4)Area Segment SID - Top Level TLV
>  
>  
> Comments:
> This seems unnecessarily profligate in its consumption of top level TLV code 
> points – something to which, as a Designated Expert for the IS-IS registries, 
>  I pay close attention.
> I can imagine an alternative encoding which utilizes a single sub-TLV within 
> the Router Capabilities TLV:
>  
> Area Proxy Router Capability sub-TLV
>  
>   Type: TBD
>   Length: Variable
>   Value: Flags + Optional sub-TLVs
>   
> 1 octet of Flags:
>  
>   0 1 2 3 4 5 6 7
>   +-+-+-+-+-+-+-+
>   |I|L|P| RSVD  |
>   +-+-+-+-+-+-+-+
>  
> I If set indicates Inside Node
> L If set indicates capable of performing Area Leader functions
> P If set indicates Proxy LSP advertisement
> RSVD - for future allocation
>  
> Followed by optional sub-sub-TLVs
>  
> Sub-sub-TLV Area Proxy System ID
> Sub-sub-TLV Area SID (Used only when P bit is set)
>  
> Please comment on this alternative.


One of the issues that drove us to introduce the Inside Node TLV was confusion 
about pseudonodes.  How does a node determine whether a pseudonode is Inside or 
Outside?  This is an important at flooding time because if it is Inside, it 
should be flooded externally.  We did not consider putting a router capability 
TLV into a pseudonode and opted for another top level TLV instead.

We chose to make the Area Proxy TLV a top level TLV because we felt that it was 
inappropriate to burden the Router Capabilities TLV with arbitrary amounts of 
additional data. In our humble opinion, the router capabilities TLV should be 
reserved for capabilities.  Yes, it’s true, we could put that data inside of 
the router capabilities TLV, but as we learned a long time ago with GUP, we can 
pretty much put anything anywhere. Just because we can doesn’t mean that we 
should.


> Additional Questions: 
> It is not clear to me why Area SID requires two different advertisements :
> 1)As a sub-TLV of Area Proxy TLV and
> 2)As a top Level TLV in the Proxy LSP
> Is it because you wanted a unique codepoint for the Proxy LSP advertisements?


We wanted the sub-TLV so that the Area Leader can distribute the value to all 
of the Inside Edge Nodes.

We wanted the top level TLV so that it could be distributed to the Outside area.


> There is a statement regarding the SR Capabilities sub-TLV advertised by the 
> Area Leader as having:
>  
>"an SRGB identical to that advertised by all Inside Routers"
>  
> SR does not require all nodes to advertise identical SRGBs. Are you imposing
> a new requirement in order to support SR and Area Proxy together? If so, what 
> happens if all Inside Nodes do NOT advertise identical SRGBs?


Yes, that is a requirement that we are imposing and it applies to the Inside 
Nodes, and possibly only to the Inside Edge Nodes.  More thought from SR 
experts would be welcome here.  

I disclaim all expertise in SR. :-)

The concern here is that the SID value advertised in the Area Segment SID TLV 
be interpreted identically by inside and outside nodes. If the SID is an index 
and the SRGBs are not identical, then there would be some inconsistency between 
how the inside and inside nodes would interpret the SID.  Thus, mismatched 
SRGBs is a misconfiguration.

Regards,
Tony

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

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

2020-06-20 Thread Les Ginsberg (ginsberg) 
(NOTE: Comments below are mine alone - wearing both my WG member hat and my 
Designated Expert for IS-IS Registries Hat. They do not represent support for 
or against the draft itself.)



draft-li-lsr-isis-area-proxy-06  currently proposes the use of one new sub-TLV 
of Router Capabilities TLV and three new top level TLVs



1)Area Proxy Router Capability - sub-TLV of Router Capability TLV



2)Inside Node TLV - Top level TLV



3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:

   Sub-TLV Area Proxy System ID

   Sub-TLV Area Segment SID



4)Area Segment SID - Top Level TLV





Comments:

This seems unnecessarily profligate in its consumption of top level TLV code 
points - something to which, as a Designated Expert for the IS-IS registries,  
I pay close attention.

I can imagine an alternative encoding which utilizes a single sub-TLV within 
the Router Capabilities TLV:



Area Proxy Router Capability sub-TLV



  Type: TBD

  Length: Variable

  Value: Flags + Optional sub-TLVs



1 octet of Flags:



  0 1 2 3 4 5 6 7

  +-+-+-+-+-+-+-+

  |I|L|P| RSVD  |

  +-+-+-+-+-+-+-+



I If set indicates Inside Node

L If set indicates capable of performing Area Leader functions

P If set indicates Proxy LSP advertisement

RSVD - for future allocation



Followed by optional sub-sub-TLVs



Sub-sub-TLV Area Proxy System ID

Sub-sub-TLV Area SID (Used only when P bit is set)



Please comment on this alternative.



Additional Questions:

It is not clear to me why Area SID requires two different advertisements :

1)As a sub-TLV of Area Proxy TLV and

2)As a top Level TLV in the Proxy LSP

Is it because you wanted a unique codepoint for the Proxy LSP advertisements?



With what I have proposed above, there is only one form of the Area SID 
advertisement but the indication of Proxy LSP is provided.







There is a statement regarding the SR Capabilities sub-TLV advertised by the 
Area Leader as having:



   "an SRGB identical to that advertised by all Inside Routers"



SR does not require all nodes to advertise identical SRGBs. Are you imposing

a new requirement in order to support SR and Area Proxy together? If so, what 
happens if all Inside Nodes do NOT advertise identical SRGBs?



   Les


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