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

[[e-mail]]

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) <[e-mail]> wrote:
> 
> Tony –
>  
> Inline.
>  
> From: Tony Li <[e-mail] <mailto:[e-mail]>> On Behalf Of [e-mail] <mailto:[e-mail]>
> Sent: Monday, June 29, 2020 2:37 PM
> To: Les Ginsberg (ginsberg) <[e-mail] <mailto:[e-mail]>>
> Cc: Hannes Gredler <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 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) <[e-mail] <mailto:[e-mail]>> 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