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) <ginsb...@cisco.com> 
> wrote:
> 
> Tony –
>  
> Inline.
>  
> From: Tony Li <tony1ath...@gmail.com <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) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>>
> Cc: Hannes Gredler <han...@gredler.at <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) <ginsb...@cisco.com 
> <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

Reply via email to