Re: [Lsr] Discussion on draft-wang-lsr-hbh-process-00

2020-11-17 Thread Tony Li


> Q1: are you using this information to determine the routing to the network? 
> On one hand, such advertisement does not effect on the normal SPF computation 
> and may be useful for traffic engineering. For example, for IOAM service, if 
> the HbH Processing Action of Node/Link is assigned to a slow processing 
> plane, the Node or Link should be excluded for path computation. If the HbH 
> Processing Action of Node/Link is ignore all extension Options header, the 
> Node/Link can be used as the normal IPv6 transit node/link. If the HbH 
> Processing Action of Node/Link is skip to Next extension Options header (e.g. 
> Routing Header), the Node/Link can be considered as Endpoints in SRv6 
> routing. On the other hand, such advertisement is useful for entities to 
> determine specific services encoded in HbH options header can be deployed in 
> a given path.
> 
> Q2: can you use the link color to compute paths?
> In the above, I answered, taking advantage of this advertisement, the exact 
> action taken by Node or Link to process HbH options header can be determined 
> (defined in Action Flag field), which can be useful for traffic engineering. 
> Hence, such advertisement is not only used to determine whether the HbH 
> options header supported by Node/Link or not. But the link color cannot 
> exactly indicate the exact action.

This suggests that you’re missing one bit of information.  Thus, could you use 
two link colors to differentiate between the two?

Tony

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


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-16 Thread tony . li

>> And how would that help connectivity restoration ? 
>> [WAJ] This action will trigger the path protection procedures, which will 
>> divert the traffic to other backup path.


This seems to be making some major assumptions about how path protection 
features operate. Those assumptions need to be
very explicitly called out.

The path protection features that I’m familiar with are triggered by 
topological changes along the existing operable path. A PUA
does not provide that.  Rather, it’s something of a temporary signal saying 
’this broke’. Without more specifics about the failure, it’s difficult to 
understand exactly what path protection should make of this.  If a prefix is 
unreachable, the obvious implication is that the associated link has
failed.  Path protection in a remote area is highly unlikely to have the 
topological details necessary to find an alternate path to that prefix.

Tony

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


Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

2020-09-29 Thread tony . li

Ron,

This is nice. It makes it clear that constraint based path computation need not 
have MPLS overhead
for those that don’t want it.

One thing that you don’t talk about is how this gets used, tho that may be 
blindingly obvious: you’ll need
all nodes placing their prefixes in the RIB/FIB, where it will need to be 
selected over other path computation
for the same prefixes.  This somewhat precludes the possibility of a given 
prefix being useful in multiple
flex-algos.

More text on application would be most welcome, just to ensure that we’re on 
the same page.

Tony


> On Sep 29, 2020, at 6:37 AM, Ron Bonica 
>  wrote:
> 
> 
> Please review and comment
> 
>   Ron
> 
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: internet-dra...@ietf.org 
>> Sent: Tuesday, September 29, 2020 9:36 AM
>> To: Parag Kaneriya ; Shraddha Hegde
>> ; Ron Bonica ; Rajesh M
>> ; William Britto A J 
>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
>> has been successfully submitted by Ron Bonica and posted to the IETF
>> repository.
>> 
>> Name:   draft-bonica-lsr-ip-flexalgo
>> Revision:   00
>> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
>> Document date:  2020-09-29
>> Group:  Individual Submission
>> Pages:  14
>> URL:
>> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
>> Status:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-
>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
>> Htmlized:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
>> Htmlized:   
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>> 
>> 
>> Abstract:
>>   An IGP Flexible Algorithm computes a constraint-based path and maps
>>   that path to an identifier.  As currently defined, Flexalgo can only
>>   map the paths that it computes to Segment Routing (SR) identifiers.
>>   Therefore, Flexalgo cannot be deployed in the absence of SR.
>> 
>>   This document extends Flexalgo, so that it can map the paths that it
>>   computes to IP addresses.  This allows Flexalgo to be deployed in any
>>   IP network, even in the absence of SR.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
> ___
> 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] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt

2020-09-15 Thread tony . li

Our apologies.  We’re on it.

Tony


> On Sep 15, 2020, at 9:04 AM, Acee Lindem (acee) 
>  wrote:
> 
> It looks like some unfortunate tab settings at least for the OSPF model...  
> Note that pyang can be used for formatting.
> 
> pyang -f yang  --yang-line-length 68
> 
> On 9/15/20, 11:47 AM, "Lsr on behalf of tom petch"  behalf of ie...@btconnect.com> wrote:
> 
>The formatting of this I-D seems to have gone wrong making it hard to read 
> and review.  The indentation of successive lines of the YANG module is more 
> than it usually is.  This was a problem with -01 that was not present in -02 
> but has now returned in -03
> 
>Tom Petch
> 
>From: I-D-Announce  on behalf of 
> internet-dra...@ietf.org 
>Sent: 14 September 2020 22:15
>To: i-d-annou...@ietf.org
>Subject: I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt
> 
> 
>A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>Title   : YANG Data Model for Dynamic Flooding
>Authors : Srinath Dontula
>  Tony Li
>Filename: draft-dontula-lsr-yang-dynamic-flooding-03.txt
>Pages   : 26
>Date: 2020-09-14
> 
>Abstract:
>   This document defins YANG data models that can be used to configure
>   and manage Dynamic Flooding for IS-IS and OSPF.
> 
> 
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-dontula-lsr-yang-dynamic-flooding/
> 
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-dontula-lsr-yang-dynamic-flooding-03
>
> https://datatracker.ietf.org/doc/html/draft-dontula-lsr-yang-dynamic-flooding-03
> 
>A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-dontula-lsr-yang-dynamic-flooding-03
> 
> 
>Please note that it may take a couple of minutes from the time of 
> submission
>until the htmlized version and diff are available at tools.ietf.org.
> 
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
> 
> 
>___
>I-D-Announce mailing list
>i-d-annou...@ietf.org
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
>___
>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

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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-07 Thread tony . li

Hi Bruno,


> At this point, area proxy spec is clear with regards to nominal behavior. So 
> indeed we are discussing error handling / transitions. (and thank you for 
> considering those cases, much appreciated).
>  
> From memory, my understanding is the area proxy nominal behaviour requires:
> -  All routers in the area are L1 & L2
> -  All inside routers advertise the area proxy TLV
> -  An area leader advertises the Area Proxy System Identifier Sub-TLV


Something that we’re not allowed to talk about in the spec is that we’re 
assuming that ALL routers in the Inside Area are configured to enable Area 
Proxy.  Partial configuration is a misconfiguration or transitional to full 
configuration.

 
> If the above is not fulfilled, what is the expected behaviour? There is a 
> priori 2 options:
> -  A) Return to regular IS-IS behaviour. i.e. all L2 LSPs from inside 
> routers are flooded to L2 outside routers
> o   Pro: no new behaviour/code as this is regular IS-IS. Correct transit 
> forwarding across the area.
> o   Con: suddenly increase size of L2 LSDB
> -  B) Keep filtering L2 LSP from inside routers
> o   Pro: no sudden increase of L2 LSDB size
> o   Con: transit traffic is partially dropped (if area LSP advertised while 
> some routers are L1 only), no transit is possible (if area LSP is not 
> advertised), or partial transit (some inside edge node do not advertise the 
> area proxy TLV).
> §  Lack of transit is not an issue if there is a backup proxy area (e.g. a 
> proxy area a replace a big single chassis).  It’s likely an issue is there is 
> no backup proxy area (e.g. the area has built-in redundancy (e.g. spife/leaf) 
> hence there is no need for another/backup proxy area. Network operator needs 
> to be well aware in order to choose the correct design (rather than 
> experience a bad surprise)
>  
> That’s an open question.
> As this point I do not have a preference, although naively I had “A” in mind. 
> From your below answer, I think that you have “B” in mind. 


Yes. Given the above assumption, we want to assume transition.


> A priori the choice may be dependent on the missing condition.
> Possibly this could be clarified in a “operational consideration” or “error 
> handling” section for network operator to be aware of the behaviour under 
> failure/transition condition.


I’m open to suggestions and/or contributions.


> FYI, I’m considering such failure to be plausible over the years as all it 
> need is one L1 router to boot and not advertise the area proxy TLV or be 
> configured as L1 only.


30 years of doing this says that any crazy thing is possible and WILL happen 
somewhere, someplace in the fullness of time. Yes, ok, withdrawing the Proxy 
LSP in these cases is probably not optimal.  What should we say instead? Some 
failures are clearly fatal, some are not. What’s the right thing to do without 
a dissertation worth of analysis and special cases?

Tony


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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-04 Thread tony . li

Hi Bruno,

 
> “A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
> Outside Router. »
> Agreed (so far)
>  
> “A Level 2 LSP with a source system identifier that is found in the Level 1 
> LSDB MUST NOT be flooded to an Outside Router.”
> I’m not sure to agree.
> If that LSP carries the Area Proxy TLV, the previous rule is enough.
> If that LSP does not carry the Area Proxy TLV, then no Area Leader advertise 
> the Area Proxy System Identifier Sub-TLV and hence the new Area Proxy is not 
> enabled. In which case I feel that normal IS-IS flooding should occur, and 
> L1-L2 nodes should have their L2 LSP flooded.
> So, I would propose to remove that sentence which doesn’t seem needed.


This was intentional. We are trying to protect against a case where a router 
boots and has not yet processed its full configuration yet.  It could easily 
generate an LSP prior to adding the Area Proxy TLV.
This could also happen during the transition to Area Proxy, where an Inside 
Node has not yet been configured for Area Proxy.

We are trying to prevent flooding of its LSP to the Outside Area because that 
may confuse other L2 nodes.


> “A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an 
> Outside Router. »
> I think we additionally need that an Area Leader advertise the Area Proxy 
> System Identifier Sub-TLV.


We already say:  

The Area Leader has several responsibilities.  First, it MUST
   inject the Area Proxy System Identifier into the Level 2
   LSDB. 


> Otherwise, hence the new Area Proxy is not enabled. I which case I feel that 
> normal IS-IS flooding should occur, and L1-L2 nodes should have their L1 & L2 
> LSP flooded.
> That condition would seem application to the whole section 5.2 or even to the 
> whole section 5



Again, we want to restrict flooding if Area Proxy is configured, even if it’s 
not fully enabled.  Again, we’re just trying to make the transition as smooth 
as possible.


Tony


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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-04 Thread tony . li

Hi Bruno,

Thank you for your comments.

> 1)
> OLD: The
>advertisement in the Proxy LSP informs the remainder of the network
>that packets directed to the SID will be forwarded by one of the
>Inside Edge Nodes and the Area SID will be consumed.
>  
> NEW:
> The
>advertisement in the Proxy LSP informs the outside area
>that packets directed to the SID will be forwarded to one of the
>Inside Edge Nodes and the Area SID will be consumed.
>  
> Motivation:
> 1)  More precise/descriptive and use the terminology defined in the draft
> 2)  The SID is a priori global in the outside area and hence will be 
> forwarded by all nodes in the outside area (and not just by the Inside Edge 
> Nodes). The destination is anycast to/toward any Inside Edge node.


Ok.


> 2)
> § 4.3.2.  The Area SID Sub-TLV
> The Area SID Sub-TLV allows the Area Leader to advertise a prefix and
>SID
>  
> §4.4.13.  The Area SID
>   The Area Leader SHOULD advertise the Area SID information in the
>Proxy LSP as a Node SID as defined in [RFC8667] Section 2.1 
> . 
>  
>  
> RFC8667 requires that for a Node SID, the prefix be an IP address (/32 or 
> /138) (rather than an IP prefix of an arbitrary length) [1]. 
> [1] https://tools.ietf.org/html/rfc8667#section-2.1.1.2 
> 
>  
> You may want to refer to this restriction when defining the Area SID Sub-TLV 
> in section 4.3.2 . e.g. :s/advertise a prefix/advertise an IP address. 
> Alternatively open the option to advertise a prefix SID without the N-Flag if 
> this is a prefix.


We are implicitly doing that by permitting a prefix.  


> 3)
> 1 typo in -04 :s/ Inisde/ Inside


Fixed, thanks.

 
> 4)
> OLD:
> The Area Leader will generate a Proxy LSP that must be flooded across
>the Inside Area.  Inside Routers MUST ignore the contents of the
>Proxy LSP other than for flooding
>  
> My personal preference would be
> NEW
> The Area Leader will generate a Proxy LSP that will be flooded across
>the Inside Area.  Inside Routers MUST ignore the contents of LSP(s) 
> originated with the Area Proxy System Identifier other than for flooding.
>  
> Motivation:
> a)  Clarify that no new behavior is involved
> b)  Specifies how the proxy LSP is to be identified as a proxy LSP.



?  Ignoring the contents of an LSP is a new behavior.  I propose something 
slightly different:

 The Area Leader will generate a Proxy LSP that will be
 flooded across the Inside Area.  Inside Routers MUST ignore
 the contents of the Proxy LSP other than for flooding.  The
 Proxy LSP uses the Area Proxy System Identifier as its Source
 ID.


>  
> 5) Open question: is the Area Proxy LSP to be advertised/read from L1 or L2 
> LSP/LSDB or both?
>  
> “All routers within the Inside Area speak Level 1 and Level 2 IS-IS on all of 
> the links within the topology.”
> OK.
>  
> “A node advertises the Area Proxy TLV in its L2 LSP”
> So my reading/guessing is that the Area Proxy TLV is only sent in the L2 LSP 
> of all Inside routers. (i.e. not in the L1 LSP).
> If so:
> -  Can you clarify the behavior when an Area Proxy TLV is received in 
> an L1 LSP? (e.g. ignore, and if not, what is the behavior when the TLV is 
> different in L1 and L2).


We already say:

   The Area Leader MUST advertise the Area Proxy System
   Identifier Sub-TLV when it observes that all Inside Routers
   are advertising the Area Proxy TLV.

The statement that you quote is pretty clear that the Area Proxy TLV is found 
in the L2 LSP.  I take it that you feel that this is insufficient.
I propose to add:

 Nodes MUST NOT advertise the Area Proxy TLV in a L1 LSP. Nodes MUST
 ignore the Area Proxy TLV if it is found in a L1 LSP. 


> -  “they will advertise the Area Proxy TLV.” May be adding “in their 
> L2 LSP”


Ok.


> -  “All Inside Edge Routers learn the Area Proxy System Identifier 
> from the Level 1 LSDB”. I would have assumed  “from the Area Proxy TLV 
> advertised in the level 2 LSDB.  So it may be a typo or I’m missing 
> something, which is very possible.


That was a bug, thanks.  I changed it to: “ … from the Area Proxy TLV 
advertised by the Area Leader … “


> o   “it MUST inject   the Area Proxy System Identifier into the Level 1 
> LSDB.” Same comment.


Also a bug.  Should be L2.  Fixed.


Thanks for the detailed review!


Tony

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


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-02 Thread tony . li

Hi Xueson,

> My intension was not to talk about math/engineering/marketing or compare the 
> size of marketing department. Them are not relevant to this thread. 


You are the one who suggested we leave it up to the market…

> I want to make clear about IETF process. In my understanding the document 
> does not need to be perfect at this stage, as long as it is in the right 
> direction to solve some acknowledged problem( IGP scalability). Comments will 
> be helpful if it could provide ideas about how to improve.


That’s what we’ve been trying to tell you all along:

- If there is a benefit to zones, it’s not clear to us.  You need to do a 
better job articulating that.

- The transition mechanisms seem awkward and painful. Can you reduce the 
complexity?

> But IMO the discussion in the mailing list about this draft has gone off the 
> rails of technology, including keeping challenging tradeoff between value and 
> complexity, which seems reasonable at the first sight, but at this stage, has 
> turned out to be a question with no right answer and may bring endless 
> argument.


Technology is all about maximizing benefits while minimizing costs.  This is 
why we don’t wire houses using gold and silver.

Yes, this does seem to be an endless argument.  Welcome to the IETF.

Regards,,
Tony

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


[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-04.txt

2020-09-02 Thread tony . li

Hi all,

This version reflects the discussion to date and the early allocation of code 
points.

Regards,
Sarah, Vivek, Gyan, & Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-04.txt
> Date: September 2, 2020 at 7:35:25 AM PDT
> To: "Tony Li" , "Gyan S. Mishra" 
> , "Gyan Mishra" , 
> "Vivek Ilangovan" , "Sarah Chen" 
> 
> 
> A new version of I-D, draft-ietf-lsr-isis-area-proxy-04.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 04
> Title:Area Proxy for IS-IS
> Document date:2020-09-02
> Group:lsr
> Pages:20
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-04
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-04
> 
> Abstract:
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that would allow level 1 areas to provide transit,
>   yet only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

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


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-02 Thread tony . li

Hi Huaimo,


> It seems that splitting L1 area A1 into two L1 areas A11 and A12 cannot 
> be automated without people's planning. Some people need to spend their time 
> in deciding where is the boundary between the two areas and selecting a 
> router in the backbone domain for Attach bit for one of the two areas. These 
> corresponds to step 1) and 3) for using Areas. 


Architectural decisions do take careful thought.  That seems to be a common 
requirement, regardless of mechanism.

Tony

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


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-01 Thread tony . li

Hi Huaimo,

> Assume that a big L1 area (say Area A1) is connected to backbone domain.
> Let us compare TTZ and Areas for scalability.
> 
> Using TTZ, we need two steps below:
> 1) configure a piece of Area A1, named P1, as a zone; and
> 2) transfer P1 to a virtual node using one command or two.
> 
> Using Areas, we need four steps below to split Area A1 into two L1 areas 
> A11 and A12:
> 1) configure the edges between A11 and A12 as L2/L1 to backbone domain;
> 2) add/configure a new area address on the routers in target Area A12;
> 3) configure Attach bit for A11 or A12; and
> 4) delete the old area address from the routers in Area A12.
> 
> Using TTZ is simpler than using Areas.


I’m not quite sure I follow you.  Are you arguing that simplicity is achieved 
through the minimum number of configuration steps?

If so, I’d like to introduce you to Arista CVP, our management platform, where 
all of this can be easily automated: 1 step.

Tony


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


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-01 Thread tony . li

Hi Xuesong,

> Apologies first if I have missed any history of this discussion. But I’m not 
> sure that we have to evaluate whether a method is “optimal” before WG 
> adoption. Why not adopt some alternative solutions and leave the choice to 
> industry/market?


First off, this is engineering, not theoretical math.  Optimal is not the 
issue. Heck, optimal isn’t even a goal.

What we are looking for is value and value that outweighs the complexity.

Leaving the choice to the market is a bad idea. The market does NOT make sound 
technical decisions. It makes pseudo-random decisions not based on technical 
merits. The canonical example here is VHS vs Betamax. Better technology lost.

Second, the market is unduly influenced by marketing. The size of your 
marketing department exceeds the size of my entire (not tiny) company. And it’s 
still second to that of Cisco.

Marketing does not make good technical and architectural decisions. That’s our 
job.

Tony

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


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-01 Thread tony . li

Hi Huaimo,

> > The question I and others have asked is “what can we do with zones that 
> > cannot be done with areas?”.
> [HC]: IS-IS TTZ or say Zone is one of a few drafts which 
> experiment/explore new ways for scalability. These new ways may be simpler 
> and have some other features.


The English language is a remarkable creature. Enormously complex and 
intricate. Maddeningly irregular and inconsistent.

The word “may” is a fine example. It denotes the possibility of a relationship 
between two concepts, but says nothing about the likelihood of the reality. As 
a result, it can be used to
conjoin arbitrary entities.

Trump MAY win the election.

COVID MAY cure cancer.

The world MAY end tomorrow.

Any sentence with the word MAY in it is equally true if you replace “MAY” with 
“MAY NOT”.

Zones MAY be simpler.  Zones MAY NOT be simpler.  It’s up to you to convince us 
that they are simpler, better, or provide some value above and beyond the 
concepts that we have now.
The obligation is on you to make this point.

So far, you haven’t.

Regards,
Tony



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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-27 Thread tony . li

Les,

 
> The statement “the … Prefix SID does NOT have the semantics that we want and 
> causes deleterious side-effects” is FALSE.


Ahem.  I disagree.  No need to be rude about it.


> There is an alternative here:
>  
> Given that there isn’t any defined use case for the Area Prefix/SID, you 
> could choose to defer its definition until such time as a use case arises.
> I agree that the concept is appealing and is potentially useful – which is 
> why I thought it worthwhile to invest time in defining it. But a conservative 
> approach might be to wait until we actually need it before defining it. It is 
> always possible that when the use case arises we will find that there are 
> some other issues which have been overlooked which might alter how this would 
> be advertised.


You’ve heard two of our customers here on the list tell you that they want 
this.  Therefore, we’re going to ship it.

Tony


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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-27 Thread tony . li

Les,

 
> [Les:] Thanx for clarifying this. A careful reading of the draft supports 
> what you say, but as this point could be easily overlooked it might be worth 
> emphasizing this in the draft.


Noted and enhanced.

> We do NOT require that the Area Leader candidates have identical 
> configurations.  In fact, if there is a configuration change, it may be 
> beneficial to configure one candidate differently and then raise its 
> priority.  It’s a simple way of effecting an area-wide configuration change.  
>  
> [Les:] Section 4.2 states:
>  
> “For consistency, all Area Leader candidates SHOULD be configured with
>the same Proxy System Id, Proxy Hostname, and any other information
>that may be inserted into the Proxy LSP.”
>  
> I would agree that the flexibility to easily propagate a config change to be 
> reflected in the Proxy LSP content requires relaxation of this rule.


This is exactly why it says SHOULD and not MUST.


> We want outside nodes to install forwarding entries on the Prefix SID.  This 
> is entirely backward compatible.  How is that inappropriate?
>  
> [Les:] Installation of forwarding entries today is based on Prefix 
> Reachability advertisements. You are proposing to extend that by requiring a 
> forwarding entry to be installed based on the context of the Area Proxy TLV.
> I would prefer that you not introduce this.


I am well aware of that.

Perhaps it would help if I tell you that I am 100% impervious to Persuasion by 
Repetition.  I understand what you want. I disagree with you on the tradeoffs.


> In addition, since there will also be a Prefix Reachability Advertisement for 
> the Area Prefix in the Proxy LSP, the IERs will have two sources of 
> information for the SID associated with the Area prefix (Area SID sub-TLV 
> from Area leader L2 LSP and Prefix Reachability advertisement in the Proxy 
> LSP). Which introduces the possibility of inconsistency.


No, since the IERs are supposed to ignore the Proxy LSP for any purpose other 
than flooding. I’m adding an explicit statement to this effect. The only source 
of truth is the Area Proxy TLV generated by the Area Leader.


> The existing ones do not have the required semantics.
>  
> [Les:] That’s wasn’t the point.



That is the entire point.  You insist that we advertise the Area SID as a 
Prefix SID in addition to the a prefix in the Area Proxy TLV.  The additional 
Prefix SID does NOT have the semantics that we want and causes deleterious 
side-effects.



> The point was that when a SID is advertised in prefix reachability it is used 
> in preference to advertisements in other TLVs.


Except when it is part of the Proxy LSP, in which case we want the Inside 
Routers to ignore it.  We do NOT want Inside Routers creating forwarding state 
or SPF state for every prefix and SID in the Proxy LSP.


> [Les:] The semantics you require are functionally equivalent to anycast 
> behavior – which is supported already.
>  
>  
> Please point me to anycast semantics that will ONLY be selected by IERs. 
> [Les:] You have specified that only IERs and Outside Routers process Proxy 
> LSP content.  So why do you ask this question?


You’re asking me to use another mechanism.  I don’t see how it applies.  I’m 
open to you educating me.

IERs do NOT process Proxy LSP content other than to flood it.

Tony


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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-26 Thread tony . li

Hi Les,

> [Les:] Any one of the IERs can be elected Area Leader, therefore all of them 
> have to be configured with the Area Prefix and associated SID.


The Area Leader may not be an IER.  In fact, in an important use case for us, 
the area is a leaf-spine topology.  The Area Leader is one of the spines.  The 
leaves are the edge routers.  For resource reasons, we do NOT want the Area 
Leader to be a leaf.


We do NOT require that the Area Leader candidates have identical 
configurations.  In fact, if there is a configuration change, it may be 
beneficial to configure one candidate differently and then raise its priority.  
It’s a simple way of effecting an area-wide configuration change.  

> Perhaps you are allowing that each IER could choose a different Area 
> Prefix/SID. Not sure why you would want to do that – but even if you did, the 
> behavior of the winning prefix/SID is analogous to an anycast address.
> The difference here is that the advertisement of the Prefix Reachability 
> associated with the area prefix is within the Proxy LSP – which appears to 
> OERs as if it was originated by all of the IERs i.e., the set of IERs appears 
> as a single node to the OERs. Still, all IERs are aware of the winning prefix 
> reachability advertisement and will do what is required in forwarding based 
> on that content.


They will not be aware of it unless we tell them via the Area Proxy TLV.  For 
obvious reasons, the Inside Nodes do NOT do anything with the Proxy LSP other 
than flood it.


> Which is why we’re using the Prefix SID.
>  
> [Les:] You are using the prefix-SID, but the advertisement is not associated 
> with a prefix reachability  advertisement, yet you want nodes to install 
> forwarding entries based on this advertisement. This is what seems 
> inappropriate.


We want outside nodes to install forwarding entries on the Prefix SID.  This is 
entirely backward compatible.  How is that inappropriate?


> The only current case where a prefix-SID is advertised and is NOT associated 
> with prefix reachability is in the Binding TLVs. This has two use cases:
> Advertising SIDs for prefixes associated with nodes which are NOT SR capable
> As an alternative to per prefix advertisement if the operator prefers to use 
> a centralized SID assignment service
>  
> In both of these cases if a SID were to be advertised in prefix reachability 
> TLV for the same prefix the SID in the prefix reachability advertisement 
> would be preferred.
> You don’t discuss this at all in the draft i.e., what happens if the SID in 
> the prefix reachability advertisement for the Area Prefix differs from that 
> advertised in the Area Proxy TLV. What I am pushing for is eliminating the 
> need to do so by relying on the existing prefix SID advertisements and not 
> introducing a new one in the Area Proxy TLV.


The existing ones do not have the required semantics.

> [Les:] The semantics you require are functionally equivalent to anycast 
> behavior – which is supported already.


Please point me to anycast semantics that will ONLY be selected by IERs. 

Tony


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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-26 Thread tony . li

Les,

> As per the draft:
>  
> Area Proxy TLV is advertised by IERs in their L2 LSP. 
> Area Proxy TLV is NOT advertised in the Proxy LSP.
> So how do the OERs become aware of the 
>  
> “prefix and  SID that represents the entirety of the Inside Area to the 
> Outside  Area”
>  
> ???
>  
> I assume that they learn this because the Proxy LSP (at least) contains a 
> Prefix Reachability TLV with the same prefix/SID that was advertised in the 
> Area Proxy TLV.
> Is this correct? If not, please correct me.


That’s correct.  If this isn’t crystal clear from the draft, please work with 
me to get it clarified to your satisfaction.


> Also explain why it is necessary for something other than a prefix 
> reachability advertisement to cause an entry to be created in forwarding for 
> a prefix – and ONLY when received in an L2 LSP?
> This is unprecedented.



It is unprecedented because there we are proposing something unprecedented.  I 
repeat: "There is no other mechanism whereby system A can advertise a prefix 
SID to a number of other systems and have them install receive/POP forwarding 
entries.”

It is NOT creating forwarding TO a prefix.  It’s reception.


> If I am right, you then have  multiple TLVs which advertise duplicate 
> advertisements – even if not in the same LSP - which exposes you to the 
> problems I mentioned.
> My goal is to have one – and only one – advertisement which creates 
> forwarding state.


Well, I’m sorry, but your goal is unachievable.  The Proxy LSP is only relevant 
outside of the area.  The Inner Node LSPs aren’t circulated outside of the area.


> My second goal is not to invent a new SID type/advertisement when the object 
> associated with it (a prefix) already has a defined SID type.


Which is why we’re using the Prefix SID.

 
> What I object to – and am concerned about – is that you seem to invent your 
> version of SR for Area Proxy even when you use the same object (a prefix) 
> that SR already supports.


Again, SR does not support the semantics that we require. 


> As you know, I was prepared to support a new type of SID when you actually 
> were defining a new object type. The fact that you decided NOT to invent a 
> new object type is fine with me – but please do not claim that you need a new 
> SID type when you don’t.


I’m sorry that you still don’t understand.  We do need something different.

Tony


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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-26 Thread tony . li


Hi Les,


> You have chosen to assign a prefix as the “Area Destination”.


Are you sure you have the right document?  The word “Destination” does not 
appear anywhere within 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03 



> This is fine with me. But having done that, forwarding should be based on the 
> existing mechanisms for advertising a prefix and the associated prefix SID.


Which is exactly what we’re doing: we’re advertising a prefix SID in the Proxy 
LSP.


If you’re referring to the Area SID advertisement, then there is no existing 
mechanism for advertising that today, that’s why we’re having to create an 
additional subTLV.
There is no other mechanism whereby system A can advertise a prefix SID to a 
number of other systems and have them install receive/POP forwarding entries.


> By doing that you avoid a number of problems:
>  
> Duplicate SID advertisements for the same prefix and the possibility of 
> inconsistency
> Differing forwarding behavior for routers (IERs) who understand the Area 
> Proxy TLV and those routers which don’t (everyone else)
>  
> You can still include a sub-TLV in the Area Proxy TLV to identify the Area 
> Prefix, but there is no need to also advertise the SID there. This makes the 
> “Area Prefix” advertisement functionally equivalent to the “Router-ID” 
> advertisement. It’s a convenient way to identify the prefix associated with 
> the area, but it does not eliminate the need to also advertise prefix 
> reachability information for that prefix in order to enable forwarding.


You seem to be asking that the Area Leader also advertise a Prefix SID in its 
own LSP, as well as a prefix in the Area Proxy TLV.  This is not just 
duplication of advertisement, it’s duplication plus a prefix.  By your own 
criteria, this suggestion is worse than what we’ve proposed.

All Inside Nodes need to understand the Area Proxy TLV and respond accordingly. 
 Only the Inside Edge Nodes need to install forwarding state for the Area SID.  
Advertising a separate Prefix SID to the Inside Nodes forces them to create 
additional forwarding state that may not be desired by the network 
administrator. 


> I have also suggested that an additional bit could be assigned in the 
> Prefix-Attributes sub-TLV (RFC 7794) to mark a prefix as an Area Prefix if 
> you wish.


Thank you, but no thanks. As you’ve seen, a large driver for doing it this way 
is backward compatibility. Adding a bit would not be helpful in that regard.

 
> But advertising a prefix-SID in two different places is a bad idea.


Advertising it in 2.5 places is worse.


> In an unrelated matter, 
> https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03#section-2 
>  
> states:
>  
> “An Inside Edge Router may be elected the DIS for a Boundary
>LAN.  In this case using the Area Proxy System Id as the basis for
>the LAN pseudonode identifier could create a collision, so the
>Insider Edge Router SHOULD compose the pseudonode identifier using
>its native system identifier.”
>  
> I understand the potential collision that could arise if the Area Proxy 
> System-Id were to be used in the pseudonode-id. However, what you propose is 
> incompatible with a strict interpretation of ISO 10589 Section 8.4.5:
>  
> “If this system, as a result of the Designated Intermediate System election 
> process, considers itself to be designated Intermediate System, the LAN ID 
> field shall be set to the concatenation of this system’s own system ID and 
> the locally assigned one octet Local Circuit ID.”
>  
> This raises the possibility that some of the non-DIS neighbors might not 
> honor the pseudo-node ID since it does not match the system-id associated 
> with their adjacency to the pseudo-node.
> At a minimum this possibility should be mentioned in the text.


This is fair and I will add a mention.  I should also point out that we have 
tested this against other implementations and not found a problem.

 
> One way to mitigate this is to have the IERs advertise a LAN Priority of 0 in 
> their IIHs so as to avoid this case.


True, or avoiding edge LANs entirely.  As you’ve previously remarked elsewhere, 
true multi-access LANs are on the decline.

Tony



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


[Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-24 Thread tony . li

Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
> Date: August 5, 2020 at 1:17:39 PM PDT
> To: 
> Cc: lsr@ietf.org
> Reply-To: internet-dra...@ietf.org, lsr@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
> 
>Title   : Area Proxy for IS-IS
>Authors : Tony Li
>  Sarah Chen
>  Vivek Ilangovan
>  Gyan S. Mishra
>   Filename: draft-ietf-lsr-isis-area-proxy-03.txt
>   Pages   : 19
>   Date: 2020-08-05
> 
> Abstract:
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that would allow level 1 areas to provide transit,
>   yet only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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


Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-20 Thread tony . li

I have reviewed the change in -10 and it seems fine to me.  Objection 
withdrawn. I support publication.

Tony


> On Aug 17, 2020, at 4:47 PM, tony...@tony.li wrote:
> 
> 
> 
>> This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
>> draft-ietf-lsr-flex-algo
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
> 
> 
> 
> Hi,
> 
> I’d like to raise an objection.
> 
> Recently, I requested (and I thought that Peter agreed to) a clarification of 
> the Min Unidirectional Link Delay.
> 
> As of version -08, the draft references RFC 7810 for the Metric-type in 
> Section 5.1.  
> 
> That RFC defines both a “Unidirectional Link Delay” (section 4.1) and 
> “Min/Max Unidirectional Link Delay” (section 4.2).
> 
> I requested that the reference be extended to specify the section.
> 
> Instead, as of -09, the reference has been changed to refer to 
> ietf-isis-te-app.  This is somewhat helpful becuase it makes it clear that 
> this should be found
> in the Application Specific Link Attributes Sub-TLV, but it still does not 
> resolve the ambiguity of which sub-sub-TLV should be used.
> 
> I would again request that this be clarified.  Proposed text:
> 
>   1: Min Unidirectional Link Delay as defined in [RFC 7810], section 4.2, 
> encoded in the Application Specific Link Attributes Sub-TLV 
> [I-D.ietf-isis-te-app].
> 
> 
> Thank you.
> 
> Regards,
> Tony
> 

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


Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-18 Thread tony . li

Les,

There is no TLV called the Min Unidirectional Link Delay.   

If the document had said “The min delay of the Min/Max Unidirectional Link 
Delay” then there would be no confusion.

Instead, it is the sloppy writing of ignoring the full name of the TLV that has 
created ambiguity.

Now, Peter has agreed to make a clarification, so:

Why are we still fighting?

Tony


> On Aug 18, 2020, at 12:18 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Tony/Robert –
>  
> Whatever clarification Peter may choose to make would be fine – but I do 
> question your casual ignoring of adjectives. 
>  
> There are three values being advertised:
>  
> 33 - Unidirectional Link Delay
> 34 – Min/Max Unidirectional Link Delay 
>  Meaning two values are advertised in this codepoint:
>  Min Unidirectional Link Delay
>  Max Unidirectional Link Delay
>  
> Now, the flex algo draft states: Min Unidirectional Link Delay
>  
> If you want to argue that “Min Unidirectional Link Delay” != “Min/Max 
> Unidirectional Link Delay” – I think you are pedantically correct.
>  
> But how that leads you to simply truncate “Min” and conclude that this is 
> really “Unidirectional Link Delay” is a leap that I cannot follow.
>  
> Perhaps you don’t really like the fact that RFC 8570 encoding combined 
> Min/Max in a single codepoint – but that ship sailed years ago.
>  
> Given that RFC 8570 is very clear in showing that the encoding includes:
>  
> 
>0   1   2   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   Type| Length|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |A| RESERVED|   Min Delay   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |   RESERVED|   Max Delay   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>  
> my ability to see your POV is somewhat limited.
>  
> Perhaps you could own that a more careful reading is possible?
>  
>Les
>  
>  
> From: Lsr  On Behalf Of tony...@tony.li
> Sent: Tuesday, August 18, 2020 10:03 AM
> To: Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; Acee 
> Lindem (acee) ; Peter Psenak (ppsenak) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>  
>  
> Robert,
>  
> Thank you, exactly.
>  
> We just need a clarification of the document.  I don’t understand why this is 
> such a big deal.
>  
> Tony
>  
> 
> 
> On Aug 18, 2020, at 9:22 AM, Robert Raszuk  > wrote:
>  
> Les,
>  
> I think this is not very obvious as Tony is pointing out. 
>  
> See RFC 8570 says: 
>  
>   TypeDescription
>   
>33 Unidirectional Link Delay
>  
>34 Min/Max Unidirectional Link Delay
>  
> That means that is someone implementing it reads text in this draft literally 
> (meaning Minimum value of Unidirectional Link Delay) it may pick minimum 
> value from ULD type 33 :) 
>  
> If you want to be precise this draft may say minimum value of Min/Max 
> Unidirectional Link Delay (34) and be done. 
>  
> That's all. 
>  
> Cheers,
> R.
>  
>  
>  
> On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) 
> mailto:40cisco@dmarc.ietf.org>> 
> wrote:
> Tony –
>  
> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you 
> are confused – nor why you got misdirected to code point 33.
>  
> RFC 8570 (and its predecessor RFC 7810) define:
>  
> 34   Min/Max Unidirectional Link Delay
>  
> This sub-TLV contains two values:
>  
> “Min Delay:  This 24-bit field carries the minimum measured link delay
>   value (in microseconds) over a configurable interval, encoded as
>   an integer value.
>  
>Max Delay:  This 24-bit field carries the maximum measured link delay
>   value (in microseconds) over a configurable interval, encoded as
>   an integer value.”
>  
> It seems clear to me that the flex-draft is referring to Min Unidirectional 
> Link Delay in codepoint 34.
>  
> I agree it is important to be unambiguous in specifications, but I think 
> Peter has been very clear.
> Please explain how you managed to end up at code point 33??
>  
>Les
>  
>  
>  
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> tony...@tony.li 
> Sent: Tuesday, August 18, 2020 7:44 AM
> To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
> Cc: lsr@ietf.org ; lsr-...@ietf.org 
> ; Christian Hopps  >; Acee Lindem (acee)  >; draft-ietf-lsr-flex-algo@ietf.org 
> 
> Subject: Re: [Lsr] 

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-18 Thread tony . li

Robert,

Thank you, exactly.

We just need a clarification of the document.  I don’t understand why this is 
such a big deal.

Tony


> On Aug 18, 2020, at 9:22 AM, Robert Raszuk  wrote:
> 
> Les,
> 
> I think this is not very obvious as Tony is pointing out. 
> 
> See RFC 8570 says: 
> 
>   TypeDescription
>   
>33 Unidirectional Link Delay
> 
>34 Min/Max Unidirectional Link Delay
> 
> That means that is someone implementing it reads text in this draft literally 
> (meaning Minimum value of Unidirectional Link Delay) it may pick minimum 
> value from ULD type 33 :) 
> 
> If you want to be precise this draft may say minimum value of Min/Max 
> Unidirectional Link Delay (34) and be done. 
> 
> That's all. 
> 
> Cheers,
> R.
> 
> 
> 
> On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) 
> mailto:40cisco@dmarc.ietf.org>> 
> wrote:
> Tony –
> 
>  
> 
> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you 
> are confused – nor why you got misdirected to code point 33.
> 
>  
> 
> RFC 8570 (and its predecessor RFC 7810) define:
> 
>  
> 
> 34   Min/Max Unidirectional Link Delay
> 
>  
> 
> This sub-TLV contains two values:
> 
>  
> 
> “Min Delay:  This 24-bit field carries the minimum measured link delay
> 
>   value (in microseconds) over a configurable interval, encoded as
> 
>   an integer value.
> 
>  
> 
>Max Delay:  This 24-bit field carries the maximum measured link delay
> 
>   value (in microseconds) over a configurable interval, encoded as
> 
>   an integer value.”
> 
>  
> 
> It seems clear to me that the flex-draft is referring to Min Unidirectional 
> Link Delay in codepoint 34.
> 
>  
> 
> I agree it is important to be unambiguous in specifications, but I think 
> Peter has been very clear.
> 
> Please explain how you managed to end up at code point 33??
> 
>  
> 
>Les
> 
>  
> 
>  
> 
>  
> 
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> tony...@tony.li 
> Sent: Tuesday, August 18, 2020 7:44 AM
> To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
> Cc: lsr@ietf.org ; lsr-...@ietf.org 
> ; Christian Hopps  >; Acee Lindem (acee)  >; draft-ietf-lsr-flex-algo@ietf.org 
> 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> 
>  
> 
>  
> 
> Hi Peter,
> 
>  
> 
> 
> 
> 
> section 5.1 of the draft-ietf-lsr-flex-algo says:
> 
> 
> Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].
> 
> We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed 
> with other delay values (max, average).
> 
>  
> 
>  
> 
> The problem is that that does not exactly match “Unidirectional Link Delay” 
> or “Min/Max Unidirectional Link Delay”, leading to the ambiguity. Without a 
> clear match, you leave things open to people guessing. Now, it’s a metriic, 
> so of course, you always want to take the min.  So type 33 seems like a 
> better match.
> 
> 
> 
> 
> 
> 
> section 7.3. of ietf-isis-te-app says:
> 
> Type   Description  Encoding
>Reference
> -
> 34  Min/Max Unidirectional Link DelayRFC8570
> 
>  
> 
>  
> 
> And it also says:
> 
>  
> 
> 33  Unidirectional Link DelayRFC8570 
> 
>  
> 
>  
> 
> This does not help.
> 
>  
> 
> 
> 
> 
> So, IMHO what we have now is correct and sufficient, but I have no issue 
> adding the text you proposed below.
> 
>  
> 
>  
> 
> What you have now is ambiguous. We have a responsibility, as writers of 
> specifications, to be precise and clear.  We are not there yet.
> 
>  
> 
> 
> 
> 
> BTW, before I posted 09 version of flex-algo draft, I asked if you were fine 
> with just referencing ietf-isis-te-app in 5.1. I thought you were, as you did 
> not indicate otherwise.
> 
>  
> 
>  
> 
> My bad, I should have pressed the issue.
> 
>  
> 
> 
> 
> 
> Anyway, I consider this as a pure editorial issue and hopefully not something 
> that would cause you to object the WG LC of the flex-algo draft.
> 
>  
> 
>  
> 
> I’m sorry, I think that this is trivially resolved, but important 
> clarification.
> 
>  
> 
> You also have an author’s email that is bouncing, so at least one more spin 
> is required.
> 
>  
> 
> Sorry,
> 
> 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] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-18 Thread tony . li

Hi Peter,


> section 5.1 of the draft-ietf-lsr-flex-algo says:
> 
> Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].
> 
> We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed 
> with other delay values (max, average).


The problem is that that does not exactly match “Unidirectional Link Delay” or 
“Min/Max Unidirectional Link Delay”, leading to the ambiguity. Without a clear 
match, you leave things open to people guessing. Now, it’s a metriic, so of 
course, you always want to take the min.  So type 33 seems like a better match.

> 
> 
> section 7.3. of ietf-isis-te-app says:
> 
> Type   Description  Encoding
>Reference
> -
> 34  Min/Max Unidirectional Link DelayRFC8570
> 


And it also says:

33  Unidirectional Link DelayRFC8570 



This does not help.


> So, IMHO what we have now is correct and sufficient, but I have no issue 
> adding the text you proposed below.


What you have now is ambiguous. We have a responsibility, as writers of 
specifications, to be precise and clear.  We are not there yet.


> BTW, before I posted 09 version of flex-algo draft, I asked if you were fine 
> with just referencing ietf-isis-te-app in 5.1. I thought you were, as you did 
> not indicate otherwise.


My bad, I should have pressed the issue.


> Anyway, I consider this as a pure editorial issue and hopefully not something 
> that would cause you to object the WG LC of the flex-algo draft.


I’m sorry, I think that this is trivially resolved, but important clarification.

You also have an author’s email that is bouncing, so at least one more spin is 
required.

Sorry,
Tony

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


Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-08-17 Thread tony . li


> This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
> draft-ietf-lsr-flex-algo
> 
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/



Hi,

I’d like to raise an objection.

Recently, I requested (and I thought that Peter agreed to) a clarification of 
the Min Unidirectional Link Delay.

As of version -08, the draft references RFC 7810 for the Metric-type in Section 
5.1.  

That RFC defines both a “Unidirectional Link Delay” (section 4.1) and “Min/Max 
Unidirectional Link Delay” (section 4.2).

I requested that the reference be extended to specify the section.

Instead, as of -09, the reference has been changed to refer to 
ietf-isis-te-app.  This is somewhat helpful becuase it makes it clear that this 
should be found
in the Application Specific Link Attributes Sub-TLV, but it still does not 
resolve the ambiguity of which sub-sub-TLV should be used.

I would again request that this be clarified.  Proposed text:

1: Min Unidirectional Link Delay as defined in [RFC 7810], section 4.2, 
encoded in the Application Specific Link Attributes Sub-TLV 
[I-D.ietf-isis-te-app].


Thank you.

Regards,
Tony

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


Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

2020-08-10 Thread tony . li

Hi Peter,

 The flex-algo draft mentions "Min Unidirectional Link Delay as defined in 
 [RFC7810 ]". When reading RFC7810, I 
 found two Sub-TLVs:
 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max Unidirectional Link 
 Delay Sub-TLV
 Could you please clarify which one should be used? If "Min/Max 
 Unidirectional Link Delay Sub-TLV" is used, will the max delay carried in 
 the subTLV be ignored?
>>> 
>>> flex-algo as defined in the draft uses "Min Unidirectional Link Delay", 
>>> which is advertised in the "Min/Max Unidirectional Link Delay Sub-TLV".
>>> 
>>> The fact that the "Min/Max Unidirectional Link Delay Sub-TLV" carries some 
>>> other data (e.g. Max delay) is orthogonal to the flex-algo usage.
>> Could we please clarify this by adding a reference to the specific section?
> 
> which specific section do you have in mind?



In the flex algo draft, in section 5.1, you current have the text:

1: Min Unidirectional Link Delay as defined in [RFC7810 
].

Could you please change that to:

1: Min Unidirectional Link Delay as defined in [RFC7810 
] Section 4.2.

Thanks,
Tony

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


Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

2020-08-10 Thread tony . li

Hi Peter,


>> The flex-algo draft mentions "Min Unidirectional Link Delay as defined in 
>> [RFC7810 > >]". When reading RFC7810, I found two 
>> Sub-TLVs:
>> 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max Unidirectional Link 
>> Delay Sub-TLV
>> Could you please clarify which one should be used? If "Min/Max 
>> Unidirectional Link Delay Sub-TLV" is used, will the max delay carried in 
>> the subTLV be ignored?
> 
> flex-algo as defined in the draft uses "Min Unidirectional Link Delay", which 
> is advertised in the "Min/Max Unidirectional Link Delay Sub-TLV".
> 
> The fact that the "Min/Max Unidirectional Link Delay Sub-TLV" carries some 
> other data (e.g. Max delay) is orthogonal to the flex-algo usage.


Could we please clarify this by adding a reference to the specific section?

Thanks,
Tony

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


Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

2020-08-07 Thread tony . li


Peter,


>> . The existing description in section 5.1 indicate that legacy encoding 
>> (RFC7810 and RFC5305) is used for link attributes. That is not correct based 
>> upon section 11. To avoid ambiguity can an explicit reference be added for 
>> [I-D.ietf-isis-te-app]?
> 
> 
> well, section 5.1. is correct. The Min Unidirectional Link Delay and TE 
> Default metric respectively were defined in RFC7810 and RFC5305. The fact 
> that we advertise them in ASLA does not change their origin.


Could we please get a clarification in section 5.1 then?  The references there 
to 7810 and 5305 without any qualification strongly suggest that the encoding 
from those RFCs should be used.


>> Could in section 11 be explicit reference to (e)ag, te-metric and delay link 
>> attributes MUST be encoded using ASLA..
> 
> Section 11 already says:
> 
>   Link attribute advertisements that are to be used during Flex-
>   Algorithm calculation MUST use the Application Specific Link
>   Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or
>   [I-D.ietf-ospf-te-link-attr-reuse].
> 
> I'm not sure what else can we say. Listing the ones we use today wold be 
> dangerous, because we may define additional ones later and we want the ASLA 
> to be mandatory for all of them.


You could add a sentence that says:

In particular, the Min Unidirectional Link Delay, TE Default Metric, 
Administrative Group, Extended Administrative Group, Shared Risk Link Group 
Value TLVs are all to be encoded iin the ASLA advertisements for use with 
FlexAlgo.

Please add any I missed.

Regards,
Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-07 Thread Tony Li

Hi Les,

> 1)Invent a new type of SID which is associated with an area.
> In this case some variation of encodings defined in V2 of the draft are 
> appropriate.


But these aren’t backward compatible, which operators clearly want.

 
> 2)Use a reachable address to get to the area. That address could be the node 
> address of the current Area Leader or an anycast address shared by all IERs.


Either of these is fine by me.  Do others care?


> IN which case existing prefix SID advertisement is appropriate coupled with a 
> means of identifying the address. There are two proposed encodings for that.


And here we haven’t come to agreement.  Do others have a preference?

Tony


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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-06 Thread Tony Li

Les,

> Not sure why this needs to be explained.


Because we are not communicating well. We are each making unstated assumptions 
that do not mesh.

When we do not communicate, it’s time to double check the basics.


> Whether you are doing label forwarding or IP forwarding, the path of the 
> packet still depends upon reaching the destination.
> If I have a unicast destination then the packet needs to reach the unique 
> advertiser of that destination.
> If I have an anycast destination then the packet needs to reach only one of 
> the possibly many advertisers of that destination.


You’re assuming that there’s actually traffic that is destined to the specified 
prefix.  I don’t share that assumption.  [Communication just improved!]

At the end of the day, we’re talking about TE here and path computation is not 
only about destinations.  It’s also about the path itself. The purpose of the 
Area SID is to provide a waypoint for path computation, not to provide a 
destination.

 
> Are you proposing for “Area SID” that we tie the SID to a prefix but alter 
> the logic such that nodes which do not advertise the prefix can be considered 
> as the final destination?
> I would not like to go down that path…


From my perspective, the entire purpose of the Area SID is to provide the SID 
value so that some controller somewhere, in its infinite wisdom, can stick a 
label somewhere in some lable stack and route packets via the Proxy Area.  The 
sole purpose of the prefix is to make SR syntax happy.  [See previous rant 
about encodings in IS-IS.] For my intent, we could use 0.0.0.0/32 and 0::0/128. 
 

Let me turn it around: what’s the simplest thing that we could do that would 
satisfy you?

Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-06 Thread Tony Li


Les,

>  There then remains the question as to whether the “Area Prefix” is anycast 
> or unicast i.e., is it common to all IERs or is it unique to whomever gets 
> elected Area Leader?
>   
> Does it matter? We have no clear semantics for this prefix. A difference that 
> makes no difference is no difference.
>  
> [Les:] This question needs to be directed at those who prefer the Area Prefix 
> approach. It matters as it impacts configuration and advertisement semantics. 
> An anycast prefix is NOT a Node Prefix.
> And it impacts how traffic is forwarded into the area.
>  
>  
>  
> How so?  Traffic will be directed to the SID value (modulo PHP). 
> [Les3:] If the prefix is private to a single router then traffic has to pass 
> through that router. If it is anycast the traffic could arrive at any one of 
> the routers supporting the anycast address.
> 


I must be missing something. My understanding of SR is that you forward based 
on the label.  Please educate me.

Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-05 Thread Tony Li

Les,

> This would make the Area Prefix mandatory for Area Proxy, which is not 
> desired.  We would prefer it to remain optional and thus part of the Area SID 
> sub-TLV.
>  
> [Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as 
> you did with the Area SID. That is what I expected you would do.


Good.  I’ve just submitted -03, which does exactly that.  Please review.  Note 
that tools.ietf.org  appears to be down at this 
instant. (??!?!?!)


> b)The remaining info (reachability and SID) can then be provided using 
> existing Prefix Reachability advertisements – no need for new sub-TLV for 
> “Area SID”. This eliminates any potential issues if the SID advertised by 
> “Area SID sub-TLV” were to differ from the SID advertised in Prefix 
> Reachability for the same prefix.
>  
>  
> As we discussed privately, we view this as a non-issue.  The Area Leader is 
> the one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a 
> coding error, there’s a coding error. There is a single source of truth (the 
> Area Leader’s config) and we cannot protect against every possible coding 
> error.  Reconciling the prefix with a separate advertisement has a 
> non-trivial chance of being broken too, and IMHO, much larger.
>  
> [Les2:] You can define the advertisements in a way which reduces the 
> possibility of ambiguity – which seems like a good thing to me.
> And rest assured that you will be asked by someone to define the expected 
> behavior when there is an inconsistency. 


Same question: same answer. :-)


> Since prefix SID and Prefix reachability are directly related in forwarding, 
> it makes far more sense to me to have those two together.
> If you find correlating information in two different TLVs too challenging, 
> you could opt for a new bit in the prefix attributes sub-TLV to identify a 
> prefix as an “Area Prefix”. Then you would not need any additional info 
> advertised in the Area Proxy TLV at all.


We prefer to keep it in the Area Proxy TLV so that its semantics are crystal 
clear.

>  There then remains the question as to whether the “Area Prefix” is anycast 
> or unicast i.e., is it common to all IERs or is it unique to whomever gets 
> elected Area Leader?
>   
> Does it matter? We have no clear semantics for this prefix. A difference that 
> makes no difference is no difference.
>  
> [Les:] This question needs to be directed at those who prefer the Area Prefix 
> approach. It matters as it impacts configuration and advertisement semantics. 
> An anycast prefix is NOT a Node Prefix.
> And it impacts how traffic is forwarded into the area.
>  


How so?  Traffic will be directed to the SID value (modulo PHP). 

Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-05 Thread Tony Li

Les,


> a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a 
> router-id today in the Router-ID TLV.


This would make the Area Prefix mandatory for Area Proxy, which is not desired. 
 We would prefer it to remain optional and thus part of the Area SID sub-TLV.


> b)The remaining info (reachability and SID) can then be provided using 
> existing Prefix Reachability advertisements – no need for new sub-TLV for 
> “Area SID”. This eliminates any potential issues if the SID advertised by 
> “Area SID sub-TLV” were to differ from the SID advertised in Prefix 
> Reachability for the same prefix.


As we discussed privately, we view this as a non-issue.  The Area Leader is the 
one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a 
coding error, there’s a coding error. There is a single source of truth (the 
Area Leader’s config) and we cannot protect against every possible coding 
error.  Reconciling the prefix with a separate advertisement has a non-trivial 
chance of being broken too, and IMHO, much larger.


>  There then remains the question as to whether the “Area Prefix” is anycast 
> or unicast i.e., is it common to all IERs or is it unique to whomever gets 
> elected Area Leader?


Does it matter? We have no clear semantics for this prefix. A difference that 
makes no difference is no difference.

Tony

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-04 Thread Tony Li

Hi Bruno,


> 
> [Bruno] Agreed so far.
> Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV? 
> We both agree that this sub-TLV has no mention of the global flag nor the 
> routing algoto be used.


So far, we do NOT have agreement on that.  Your argument yesterday (backed by 
Robert) is pretty compelling: go ahead and assign a prefix and now the Area SID 
may be advertised as a Node SID in the Proxy LSP. If we take that direction, 
this discussion is moot.

Tony

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread tony . li

Hi Robert,

> How about we first define an "Area Prefix" (IP address being a property of an 
> area) then assign SID to it ? 


That’s effectively what Bruno is proposing.  It adds some additional 
configuration and management overhead.  Do you think it’s worthwhile?



> How odd it may sound I would like to still be able to direct traffic (read ip 
> tunnel) traffic to an area without any SID. 



Well, that becomes an anycast tunnel endpoint, which is actually not one of the 
goals for Area Proxy.

Tony


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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread tony . li

Hi Acee,

> [Acee] I know you guys have all thought about this a lot more than myself. 
> However, I’d envisioned this new Area SID as taking one to the closest entry 
> to the abstracted area. The next SID in the stack would either take you to a 
> destination inside the area or would use the abstracted area as transit to 
> another SID.

I believe that is the core of the semantics that we are all agreed upon.  The 
question is how to get there.

Tony


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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-31 Thread tony . li

Hi Bruno,

Thank you for the clarification.  I understand completely what you’re trying to 
do and I agree that it’s valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID. Not unthinkable.
What do the Inside Nodes do with this prefix, if anything?  

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from addressing. The one, true
way within IS-IS is the system ID, a separate, independent namespace for nodes 
that simply avoids ALL of these problems.  If RFC 8667 
encoded node SIDs as their own TLV without the unnecessary prefix that OSPF’s 
style mandates, this would be trivial.



> On Jul 31, 2020, at 2:24 AM, bruno.decra...@orange.com wrote:
> 
> Hi Tony,
>  
> Thank you for your reply.
> Top posting the description of the use case that I have in mind.
>  
> Ø  First off, the Area SID is 100% optional. If you choose not to use it, 
> then the Proxy LSP should be 100% compatible with a standard L2 node.
> Good. But I think that the idea of the Area SID is a good one, and I choose 
> to use it. Then I’d like to get it for free ;-)
>  
>  
> Please fine below a network topology:
> 
>  
>  
> My understanding is that the L2 topology seen by node S is the following
> 
>  
> P been the Proxy LSP.
>  
> S wants to protect from the failure of link S-C by using TI-LFA. For the 
> destination C, it would push 2 (*) node SIDs: P, C 
> So S needs a Node SID for P:
> a)  If P does not redistribute the Node SIDs from its area members, P 
> does not seem to advertise any node SID currently. There is a chance that C’s 
> TI-LFA implementation would not like it and hence would not install 
> protection for this (link, destination)
> b)  If P redistributes the Node SIDs from its area members, P advertises 
> 3 node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
> forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.
>  
> Two solutions I could think of:
> - when redistributing the node SID, P changes the SIDs values and replace 
> them with the value of the Area SID. This works for this use case, but it is 
> borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, 
> we have some SID conflict. Let’s try to avoid this subject).
> - P could advertise its own Node-SID with the Area SID value. This is what 
> I’m proposing. Both the IP loopback and the Area SID of this Node SID  are 
> likely configured by the network operator so this does not seem like a 
> significant effort from the implementation.
>  
> As you say, this does not involve any protocol extension. But the goal is to 
> improve interop with existing/legacy L2 nodes so this may be valuable in the 
> draft. This point could be pushed to a deployment consideration section if 
> you don’t want any impact on the protocol extension.
>  
> Thanks,
> --Bruno
>  
> (*) Assuming the right metrics on the links. This is not the subject of this 
> thread.
>  
>  
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Thursday, July 30, 2020 7:39 PM
> To: DECRAENE Bruno TGI/OLN 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for 
> draft-ietf-lsr-isis-area-proxy-02.txt
>  
>  
> Hi Bruno,
>  
> Thank you for your comments.
>  
> 
> 
> On Jul 30, 2020, at 9:22 AM, bruno.decra...@orange.com 
> <mailto:bruno.decra...@orange.com> wrote:
>  
> Hi Tony,
>  
> Thanks for the updated draft.
>  
> “ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
>represents the entirety of the Inside Area to the Outside Area.  This
>sub-TLV is learned by all of the Inside Edge Nodes who should consume
>this SID at forwarding time.”
>  
> Excellent, from my perspective.
>  
> Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.
>  
> “When SR is enabled, it may be useful to advertise an Area SID which
>will direct traffic to any of the Inside Edge Routers.  The Binding/
>MT Binding TLVs described in RFC 8667 Section 2.4 
> <https://tools.ietf.org/html/rfc8667#section-2.4> are used to
>advertise such a SID.
>  
>The following extensions to the Binding TLV are defined in order to
>support Area SID:
>  
>   A new flag is defined:
>  
>  T-flag: The SID directs traffic to an area.  (Bit 5) »
>  
>  
> This works.
>  
>  
> Excellent.
>  
> 
> 
> However I may have a 

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-30 Thread tony . li

Hi Bruno,

Thank you for your comments.


> On Jul 30, 2020, at 9:22 AM, bruno.decra...@orange.com wrote:
> 
> Hi Tony,
>  
> Thanks for the updated draft.
>  
> “ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
>represents the entirety of the Inside Area to the Outside Area.  This
>sub-TLV is learned by all of the Inside Edge Nodes who should consume
>this SID at forwarding time.”
>  
> Excellent, from my perspective.
>  
> Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.
>  
> “When SR is enabled, it may be useful to advertise an Area SID which
>will direct traffic to any of the Inside Edge Routers.  The Binding/
>MT Binding TLVs described in RFC 8667 Section 2.4 
>  are used to
>advertise such a SID.
>  
>The following extensions to the Binding TLV are defined in order to
>support Area SID:
>  
>   A new flag is defined:
>  
>  T-flag: The SID directs traffic to an area.  (Bit 5) »
>  
>  
> This works.


Excellent.


> However I may have a different deployment environment than the one you have 
> in mind. Even if those issues may be mine, allow me to share them with you.
> In many WAN networks than I’m used to, there are routers from different 
> vendors, platforms, software, generations. Requiring all those routers to 
> support the new Binding SID TLV T-Flag will take time. Some platform may even 
> be end of engineering (evolutions) so would never support such new features.
> In my environment, ideally, I would prefer a solution which do not require 
> any new feature on external L2 nodes, while all existing L2 features keep 
> working, in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would 
> require the Proxy LSP to be not (significantly) different than the LSP of a 
> vanilla L2 node.


First off, the Area SID is 100% optional. If you choose not to use it, then the 
Proxy LSP should be 100% compatible with a standard L2 node. 

I cannot claim that we’ve exhaustively tested our implementation against all of 
the features that you cite, so there may still be corner cases, but our intent 
is to make that doable.  For exaple, the Proxy LSP can still contain a node 
SID, adjacency SID, and prefix SID as before. There’s no change there.


> For SR, I think that this would require this Proxy LSP to advertise a 
> Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID 
> is advertised with an IP address that would need to be provisioned.


That’s certainly doable and requires no new protocol machinery. If the WG 
prefers this mode of operation, I’m not opposed.

 
> Both approaches are not mutually exclusives. I’d be happy enough with an 
> option for the Proxy LSP to advertise an Area Node SID with the Area SID 
> attached.
>  
> Finally, there is no requirement to make me happy ;-) . The above could also 
> be a local implementation knob not mentioned in the draft.


Our goal is to make as many customers as happy as possible.  ;-)

Tony

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


[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-25 Thread tony . li

Hi folks,

This version of the draft reflects major changes in line with the discussions 
that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the 
advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion 
on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
> Date: July 25, 2020 at 6:46:05 PM PDT
> To: "Vivek Ilangovan" , "Sarah Chen" 
> , "Gyan S. Mishra" , "Gyan 
> Mishra" , "Yunxia Chen" , 
> "Tony Li" 
> 
> 
> A new version of I-D, draft-ietf-lsr-isis-area-proxy-02.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 02
> Title:Area Proxy for IS-IS
> Document date:2020-07-25
> Group:lsr
> Pages:20
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-02
> 
> Abstract:
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that would allow level 1 areas to provide transit,
>   yet only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

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


Re: [Lsr] Request WG adoption of TTZ

2020-07-17 Thread tony . li

Hi Huaimo,

> > “reducing the service interruption, making operations to be simple, and 
> so on”
>  does not require introduction of zones.  We can already do so using areas – 
> including merging/splitting of an area.
> 
> [HC]: Smooth merging/splitting of an area seems not reduce the service 
> interruption while Area Proxy is abstracting an existing IS-IS area to a 
> single node because the adjacency ups and downs. IS-IS TTZ seems reduce the 
> service interruption while it is abstracting a zone to a single node since it 
> provides a smooth transferring from a zone to the single node. In addition, 
> operations on IS-IS TTZ for abstracting a zone to a single node seems simpler 
> than creating a new L1 area (through merging/splitting of an area in some 
> cases) and abstracting the L1 area to a single node.
> 
> > Until you demonstrate something compelling which cannot be done with an 
> > area but can be done with a zone, I simply do not see why we need to 
> > introduce zones to the protocol..
> 
> [HC]: It seems that “reducing the service interruption, making operations to 
> be simpler" provided by IS-IS TTZ with a zone should be compelling enough.
> 


My apologies if this comes off as too preachy, but perhaps it will help if we 
are a bit more explicit about out thinking in case language is gettiing in the 
way. 


Engineering is all about trade-offs. With everything that we design there are 
benefits (hopefully) and costs (hopefully obvious). In any design, we want the 
benefits to outweigh the costs. Unfortunately, the evaluation of those benefits 
and costs are subjective. 

You’ve just seen Area Proxy go through a major revision because some of us felt 
that the costs (a couple of extra TLV code points) were too high.  Some of us 
disagree. ;-)

No one is suggesting that the zone concept has no value. No one is saying that 
smooth transitions have no value. It’s very clear that they do.  If we could do 
that with zero costs, we certainly would. However, the costs are non-zero in 
additional complexity and additional code.

What we’re trying to tell you is that in our humble opnion, the tradeoff isn’t 
in favor of TTZ. The costs are higher than the benefits.

There is no definitive right answer in subjective situations. We, as a 
community, have to come to rough consensus. Frequently to get there, there have 
to be compromises and tough decisions.

Regards,
Tony

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


Re: [Lsr] Request WG adoption of TTZ

2020-07-13 Thread Tony Li

Hi Huaimo,


> 1).  It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ 
> abstracts a zone to a single node. This abstraction is supported by the 
> extensions to IS-IS, and some of these extensions are not defined in Area 
> Proxy. For example, the extensions for the edge nodes of the zone are not 
> defined in Area Proxy.
> 
> The details is underlined above. It says that some of the extensions in 
> IS-IS TTZ are not defined in Area Proxy. It seems accurate if we look at the 
> details


Apparently, we have very different understandings of the words “amended to”.

And so it goes.

Regards,
Tony


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


Re: [Lsr] Request WG adoption of TTZ

2020-07-13 Thread Tony Li


Hi Huaimo,


> 1).  It seems that Area Proxy can not be amended to IS-IS TTZ. 



I feel that this is somewhat imprecise.

From my perspective, our attempts to collaborate have been hampered by 
governmental regulations that are wholly out of our control. The suggestions 
that I’ve made for continued collaboration within the bounds of those controls 
have not been well received. Thus, to say that something cannot be done is 
overstating the case.  We have simply not been wiilling to do so, which is most 
unfortunate.  Who can say what could happen if we could find a way for all 
three proposals to collaborate?

Regards,
Tony

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-08 Thread tony . li

Hi Les,


> Again, the subTLVs of the area proxy TLV are for the coordination of the 
> Inside Area. The Area Proxy TLV appears in the Inside Node’s normal LSP.
>  
> The Proxy LSP is for informing the Outside Area.
>  
> [Les:] Understood – but I do not see why this requires you to advertise the 
> SID in two different TLVs. As you allow the Binding SID TLVs to be advertised 
> in both standard LSPs and Proxy LSPs, there seems to be no need for two 
> different TLVs to include the advertisement.
> ??


The semantics are completely different. Advertising it in the Binding TLV is 
permission to use the SID for packet forwarding.

The advertisement in the Area Proxy LSP is to instruct the Inside Nodes to use 
that SID to establish the forwarding state.  


> [Les:] Yes – of course – this is pathological. (Probably not hilarious to the 
> customer.  )


No doubt, but I’ve found that if one doesn’t regard bugs with some humor, our 
profession would be morose, in the extreme.


> I am just saying by having two sources for the advertisement you introduce 
> the possibility of inconsistency – and the spec would have to speak to this – 
> even if it should not happen.


Ummm…. Not sure what I can say other than “don’t write bugs”.  But ok, I’ll 
happily do so.


> We are abusing the definition of the Binding TLV.  2.4 says: "The SID/Label 
> Binding TLV may be used to advertise prefixes to SID/Label mappings.”  That’s 
> not what we’re doing, so it’s not too surprising that there’s some conflicts.
>  
> [Les:] Yes – the Binding TLV has some issues being generalized. There is 
> history here as to why the format is the way it is and why it isn’t more 
> easily extensible – and that is open for discussion AFAIAC, but we cannot 
> break backwards compatibility for SR.


Agreed, trying not to. :-)


> But I am also responding (in part) to your desire to make the Area Segment 
> SID a more general tool – usable outside of Area Proxy – which seems like a 
> good goal.


And you’ve requested that we put the Area Segment SID in the Binding TLV.  I’ve 
tried to do so and you don’t like how I’ve done it.  Please tell me what I can 
do that will satisfy you.  From what you’ve said so far, there is no legal way 
to use the Binding TLV.

Catch-22.  Yossarian!

Regards,
Tony

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-08 Thread tony . li

Hi Les,


> The new definitions in the latest version in the draft are very close to what 
> we discussed in the earlier thread – so this looks pretty good to me.


Excellent, thanks.


> I still have some concerns regarding the Area Segment SID.
> You propose to advertise this in two places:
>  
> 1)As a sub-TLV of the new Area Proxy TLV
> 2)As a new sub-TLV of the existing Binding TLVs (149, 150)
>  
> I am not sure why you need this in the Area Proxy TLV as you allow Binding 
> TLVs to be advertised in the Proxy LSPs (Section 4.4.10).
> ???


Again, the subTLVs of the area proxy TLV are for the coordination of the Inside 
Area. The Area Proxy TLV appears in the Inside Node’s normal LSP.

The Proxy LSP is for informing the Outside Area.

It’s fairly important that we install the forwarding state for the Area Segment 
SID and distribute the Proxy System ID before we advertise the Proxy LSP.


> If this is what is intended, it raises a number of concerns:
>  
> If both are present and inconsistent how are they used?


If both are present and inconsistent, then we have a major malfunction of the 
Area Leader, since it is the single system that is intentionally advertising 
both.

The Inside Nodes would follow the contents of the Area Proxy TLV and employ one 
SID value.

The Outsiide Nodes would follow the contents of the Proxy LSP and employ a 
different SID value.

Hilarity ensues.

Note that this is somewhat analogous to a system that wished to advertise a 
loopback interface and advertised one prefix into L1 and another prefix into L2.


> As Area Proxy TLV does not support MT (not suggesting that it should) it 
> isn’t clear how this relates to MT context – which exists for TLVs 149/150.
>  
> Encoding wise, if we are to support Area Segment SID in the Binding TLVs, I 
> think more detail needs to be provided as to flag settings when the new 
> sub-TLV is present.
> The following flags are currently defined for the Binding TLVs:
>  
> 0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
> |F|M|S|D|A| |
> +-+-+-+-+-+-+-+-+
>  
> F,S,D flags seem applicable w/o change.
> However, M flag would need to be clear when Area Segment SID is present.
> The A flag seems not applicable to Area Segment SID
> And your encoding violates the current definition of Binding TLVs.
> Specifically, https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.4 
>  states:
>  
> “The Prefix-SID sub-TLV is defined in Section 2.1 
>  and contains 
> the SID/Index/Label value associated with the prefix and range.
>  The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
> M-Flag is clear.
>  The Prefix-SID sub-TLV MUST NOT be present when the M-Flag is set.”
>  
> While some changes to this definition are likely required to support Area 
> Segment SID no matter what, it is hard for me to see a good way to do this 
> w/o adding a new flag.


I’m open to suggestions here.

We are abusing the definition of the Binding TLV.  2.4 says: "The SID/Label 
Binding TLV may be used to advertise prefixes to SID/Label mappings.”  That’s 
not what we’re doing, so it’s not too surprising that there’s some conflicts.

Tony


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


Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread tony . li

Hi Aijun,

Subdividing an existing area is entirely possible with Area Proxy.  You just 
have to split the area and then apply Area Proxy.  ;-)

Tony


> On Jul 7, 2020, at 7:36 PM, Aijun Wang  wrote:
> 
> Hi, Les:
> 
> Using TTZ to sub divide the existing area seems more attractive. It seems TTZ 
> can accomplish all the functions Area Proxy can provide, but area proxy can’t 
> cover the scenarios that TTZ can solve.
> Why don’t we prefer to TTZ?
> 
> Aijun Wang
> China Telecom
> 
>> On Jul 8, 2020, at 08:53, Les Ginsberg (ginsberg) 
>>  wrote:
>> 
>> 
>> Huaimo –
>>  
>> Sorry for ascribing area merging properties to zones... As the base protocol 
>> mechanism in IS-IS can be used both to split and merge areas I was thinking 
>> zones could be used the same way, but I see on closer reading that you have 
>> restricted a zone to be a subset of an area (which could also be the area 
>> itself).
>>  
>> I think this does not detract from the main point I am trying to make – 
>> which is that unless there is reason to believe that operators would prefer 
>> to use zones rather than split an area (when necessary), this does not serve 
>> as a significant differentiator between TTZ and area-proxy.
>> I think you need a more compelling differentiator to justify proceeding with 
>> both drafts.
>>  
>> In this regard I am agreeing with the points made by other folks (notably 
>> Chris and Tony), that the introduction of zones may well be adding unneeded 
>> complexity.
>>  
>> Just my opinion of course…
>>  
>>Les
>>  
>>  
>> From: Huaimo Chen  
>> Sent: Tuesday, July 07, 2020 12:42 PM
>> To: Les Ginsberg (ginsberg) ; Christian Hopps 
>> 
>> Cc: lsr@ietf.org; lsr-cha...@ietf.org
>> Subject: Re: [Lsr] Request WG adoption of TTZ
>>  
>> Hi Les,
>>  
>> > I think what you are highlighting is that w TTZ an operator could apply 
>> > the solution to a subset of an area (which you call a zone) – or to a set 
>> > of areas (which you also call a zone). This presumes that it is expected 
>> > that a customer would want to operate in a mode where the interconnections 
>> > do not follow area boundaries. It isn’t clear to me that this is a 
>> > compelling requirement. If there are operators who feel otherwise I would 
>> > appreciate them speaking up and educating us on the requirements.
>>  
>> How do you get that TTZ could be used to a set of areas (which you also call 
>> a zone)? 
>> A zone is a piece or block of an area.  In an area, we can define one or 
>> more zones. All these zones are within this area. For a set of areas, we can 
>> define one or more zones in each of these areas.. But we can not define a 
>> zone crossing multiple areas.
>>  
>> Best Regards,
>> Huaimo
>> From: Les Ginsberg (ginsberg) > >
>> Sent: Tuesday, July 7, 2020 3:29 PM
>> To: Huaimo Chen > >; Christian Hopps > >
>> Cc: lsr@ietf.org  mailto:lsr@ietf.org>>; 
>> lsr-cha...@ietf.org  > >
>> Subject: RE: [Lsr] Request WG adoption of TTZ
>>  
>> Huaimo –
>>  
>> I think what you are highlighting is that w TTZ an operator could apply the 
>> solution to a subset of an area (which you call a zone) – or to a set of 
>> areas (which you also call a zone). This presumes that it is expected that a 
>> customer would want to operate in a mode where the interconnections do not 
>> follow area boundaries. It isn’t clear to me that this is a compelling 
>> requirement. If there are operators who feel otherwise I would appreciate 
>> them speaking up and educating us on the requirements.
>>  
>> Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
>> should be focusing on things other than the flexibility of zones over areas.
>>  
>>Les
>>  
>>  
>> From: Huaimo Chen > > 
>> Sent: Tuesday, July 07, 2020 11:13 AM
>> To: Les Ginsberg (ginsberg) > >; Christian Hopps > >
>> Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
>> 
>> Subject: Re: [Lsr] Request WG adoption of TTZ
>>  
>> Hi Les,
>>  
>> Thank you very much for your comments.
>>  
>> There are still some differences between Area Proxy and TTZ regarding to 
>> IS-IS with smooth area splitting and merging. 
>>  
>> At first, the operations/configurations are different. 
>> Using Area Proxy, two steps are needed. One step is to split an IS-IS 
>> area to multiple areas through some configurations. The other step is to 
>> abstract an existing IS-IS area to a single pseudo node through another set 
>> of configurations. 
>> Using TTZ, only one step is needed, which is to abstract a zone to a 
>> single pseudo node.
>> From operations' point of view, TTZ seems simpler.
>>  
>> Secondly, TTZ provides smooth transferring between a zone and its single 
>> 

Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread Tony Li

Hi Huaimo,

> Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
> Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
> defined in the Area Proxy draft) include:


That’s an unfortunate assumption.  We have not defined OSPF Area Proxy because 
it’s frankly well outside of our expertise.

The hierarchical structures of OSPF and IS-IS are intrinsically different.  
While legacy IS-IS allows L2 traffic to transit an L1L2 area, my understanding 
is that when OSPF traffic leaves Area 0, it won’t be coming 
back.  While I don’t particularly like this aspect of the OSPF architecture, 
it’s NOT what we were out to fix.  

So, please don’t assume anything about OSPF Area Proxy.  

Tony

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


Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread tony . li
>> Moreover, TTZ provides smooth transferring between a zone and its single 
>> pseudo node. That is that a zone can be smoothly transferred to a single 
>> pseudo node, and the pseudo node can be smoothly rolled back to the zone.
> 
> This strikes me as the important difference from area proxy. It certainly 
> adds complexity to things, I wonder if it's worth it?


FWIW, we looked at this quite seriously a while ago. Turning abstraction on and 
off is simply not a daily occurrence. Doing it properly requires careful 
thought and planning. 
Where are the boundaries? What prefixes will be advertised and with what 
metrics? How will the affect traffic flow?

The corner cases that happen when you are in this transition are large. We have 
to deal with the issue of the metrics that are abstracted away.  We chose to go 
down the path
of intra-area vs. inter-area metrics, exactly as OSPF does. But if you do this, 
then you have an issue: the metrics are different when abstraction is enabled 
or disabled and 
different nodes will compute different paths depending on which LSPs have 
propagated to them. This seemed like a wonderful opportunity for forwarding 
loops. This
is especially problematic when abstraction is enabled, as there is now an 
entire area’s worth of LSPs that need to age out before you can be assured of 
consistency.
Yes, you can try to purge them, but purges aren’t the most reliable thing in 
the world.  

Net net, we felt that the complexity exceeded the benefit. Yes, there is 
benefit there, but from the pragmatic viewpoint of making it work in 
production, the risks and costs seemed very high. 
We expect that operators would want to make the change in a maintenance window 
anyway, and as long as you’re having a maintenance window, you might as well do 
things the
simpler way.

Regards,
Tony

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


[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

2020-07-07 Thread tony . li

Hi all,

We’ve updated our draft to revise the TLV encodings along the lines of the 
discussions we’ve been having.

1) The Area Proxy Router Capability is removed.
2) The Inside Node TLV is removed. Instead, the Area Proxy TLV is used instead.
3) The Area Segment SID is advertised inside of a SID/Label Binding TLV. While 
we discussed using 
a flag within this TLV to denote that this was an Area Segment SID, after 
looking at it, it seemed simpler
and more consistent to use a sub-TLV.

Please review and comment.

Thanks,
Sarah, Vivek, Gyan, and Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt
> Date: July 7, 2020 at 8:14:58 AM PDT
> To: "Gyan Mishra" , "Vivek Ilangovan" 
> , "Sarah Chen" , "Tony Li" 
> , "Gyan S. Mishra" , "Yunxia 
> Chen" 
> 
> 
> A new version of I-D, draft-ietf-lsr-isis-area-proxy-01.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 01
> Title:Area Proxy for IS-IS
> Document date:2020-07-07
> Group:lsr
> Pages:19
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-01
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-01
> 
> Abstract:
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that would allow level 1 areas to provide transit,
>   yet only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

___
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 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 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 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-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] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-21 Thread tony . li

Hi Les,


> I am not yet overly enthused about approaches which promote non-hierarchical 
> network architectures. But it seems clear that there is interest in deploying 
> non-hierarchical solutions and both drafts present solutions
> which merit further evaluation.


I think that there’s some confusion here. The point is very much to have a 
hierarchical design.  The key point is that the IGP hierarchy must not require 
a hierarchical data plane.  While a hierarchical data plane may suffice in a 
WAN topology, imposing that restriction on mega-scale multi-dimensional Clos 
fabrics simply doesn’t fly.  

We want the hierarchy provided by the IGP.  We need tools for extreme scaling. 
We need the IGP abstractions decoupled from the data plane architecture.

Looked at sideways, we’re simply trying to generalize the IS-IS area mechanism. 
We need transit areas that do not impact the scale of L2.

Apologies if I’m simply restating what Tony P. has already said.

Regards,
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 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 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


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li

Tony,

> If we rely on controller fixing LPM as well under failures then really, who 
> needs IGPs anymore anyway except for bunch of loopbacks and SPF for the 
> controller to do all the FIB work and hence discussions like high hierarchies 
> or anisotropic routing are largely superfluous me thinks ;-) 



A fair point that many seem to agree with. The IGP provides topology for the 
controller and it simply dominates the control plane. The issue, of course, is 
recovery.  The IGP is still a necessity to provide reachability to the 
controller and to deal with failure recovery. 

I agree that people who do go down the controller path may avoid certain 
issues. It also seems to be true that folks who avoid the controller path avoid 
other issues.

Choose your battles…

T

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


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li


> On Jun 15, 2020, at 10:56 AM, Tony Przygienda  wrote:
> 
> PNNI had transit areas in hierarchy working but the trick was connection 
> setup cranck-back. Such a thing would work for RSVP or any of the stateful 
> connection setups but alas, this is not fashionable right now. Unfortunately, 
> generic hierarchy with reachability summarization ends up  with very 
> sub-optimal routing or black-holing on aggregates since we cannot "back-off" 
> generic LPM packet forwarding when we realize we're @ a dead end due to 
> aggregation. To prevent bi-furcation of topology or transit horizontals 
> several solutions exist, one of which (configure hierarchy statically 
> everywhere) the current draft has in now but alas, the topology is star of 
> stars (you can actually see CLOS conceptually as something like this as well 
> ;-)


Hi Tony,

The modern solution of choice is to relegate all of the traffic engineering to 
an out-of-band controller that no longer operates in real-time and has the 
scale to span levels and areas.

Tony

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


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li

Hi Robert,


> > It’s very clear that this is inadequate.   
> 
> Doesn't this really depend how you architect multiple levels ? Sure you have 
> some physical topology - but it seems to me that the trick is in properly 
> laying out levels on top of them and between them. 


The very pragmatic viewpoint is that network architects will construct the 
physical topology that best suits their traffic pattern and that trying to 
contort that physical topology into some kind of hierarchy will create 
additional (and perhaps significant) cost.  People don’t want to do that.  They 
want scalable networks that match their physical topology.  For this to work, 
our hierarchical abstractions need to be independent of the topology and that 
forces us into having transit areas.


> To my original question - how many levels can you run on the physical box ? 
> And can levels be locally and logically interconnected ? 


The constraint on a physical box is the amount of memory and CPU.  Running 8 
levels, each with 1000 LSPs per level is not out of the realm of doable within 
the next decade.

Yes, levels can be logically interconnected through higher levels.

I don’t understand what you mean by ‘locally interconnected’.


> Then of course if you have applications (MPLS exact FEC match or SR-MPLS with 
> SRLBs) which do not allow any aggregation you are pretty much stuck no matter 
> what :).


Broken architectures are everywhere. Folks that have solutions that do not 
allow for a hierarchical control plane are necessarily going to have issues. 
Hierarchy is the only tool that we have to fight scalability.

Tony


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


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li


Hi Henk,

> It's not so clear to me, sorry.
> Does anyone have an example (link or jpg) of a (sensible) topology
> that would not work with multiple levels of hierarchy, but works
> nicely/better with area-proxies (or FRs) ? Just curious.


Certainly.  Draw a 3x3 grid with nodes at each intersection.

Replace each node with an L1 area.

Image: 
https://upload.wikimedia.org/wikipedia/commons/0/0f/Figure_11-_a_three_by_three_grid.png


>> The structure of legacy
>> IS-IS areas effectively precludes a scalable network for using lower
>> levels for transit. This constrains ISPs to ‘cauliflower’ topology
>> where you have L1 on the outside, L2 just inside of L1, L3 inside of
>> L2, etc.
> 
> I understand. L1-8 forces a hierarchical network designs.
> But even if one would have the tools to design a non-hierarchical
> network, that doesn't mean one should do so. :-)


Hierarchical abstraction is a fine thing, but traffic cannot be constrained to 
be hierarchical. Doing so forces the top of the hierarchy to have capacity that 
is greater than lower levels. Pragmatically, we can’t build things that have 
infinite capacity, so we have to make do with finite sized switching elements. 
Fortunately Clos taught us how to do this. :-)

The result is that we need to have transit areas.


> If there are spots in the network where the hierarchical constraints
> are a problem in the real world, indeed it would be nice to have tools
> like area-proxies in the tool-set, to help solve those problems.
> 
> I would like to have both tools.
> I think you do too (as you are author of both drafts).


I concur.

Tony

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


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread tony . li


> On Jun 15, 2020, at 3:45 AM, Henk Smit  wrote:
> 
> BTW, personally I think the proper solution to scale IS-IS to larger
> networks is 8 levels of hierarchy. Too bad that idea gets so little
> push from vendors and operators.


Hi Henk,

It’s very clear that this is inadequate.  The structure of legacy IS-IS areas 
effectively precludes a scalable network for using lower levels for transit. 
This constrains ISPs to ‘cauliflower’ topology where you have L1 on the 
outside, L2 just inside of L1, L3 inside of L2, etc.  

We already see networks who are unwilling to use the two levels that we have 
today due to this constraint.

Regards,
Tony

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


Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-10 Thread tony . li

> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.


I am not a lawyer nor an author, but the area proxy IPR filing 
(https://datatracker.ietf.org/ipr/4016/ 
)  may also apply to this draft.

Tony

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


Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-10 Thread Tony Li


> On Jun 10, 2020, at 12:27 PM, Christian Hopps  wrote:
> 
> This begins a 2 week WG adoption call for the following draft:
> 
>  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
> 
> The draft would be adopted on the Experimental track.
> 
> Please indicate your support or objection by June 24, 2020.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.


Support, as author.

IPR has been filed: https://datatracker.ietf.org/ipr/4016/ 


Tony

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


Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

2020-06-10 Thread tony . li

Tony,


> On Jun 10, 2020, at 9:40 AM, Tony Przygienda  wrote:
> 
> You do seem to be carrying as WG member a hot torch for area-proxy for some 
> reason, that's fine with me, frankly, I had extensive discussions with 
> customers when DriveNet was being proposed to them (which AFAIS is basically 
> area-proxy) and the solution is intriguing but it did not cut lots of 
> requirements of large customers and there are a lot of unresolved issues 
> operationally with an approach like that. 


Drivenets, as I understand it, is an attempt to physically deaggregate a 
multi-chassis fabric down to the chip level using a proprietary 
chip-set-specific cell based interlink protocol. However, it retains a single 
control plane and as such looks like a single IS-IS system.  It has no 
relationship whatsoever to area proxy.

Regards,
Tony



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


Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-06-05 Thread tony . li

Hi,


> I have a question regarding the draft. At the end of section 3, it says if 
> there is any change in the base topology, the flooding topology MUST be 
> re-computed. So in case of a link failure in the base topo, it’s possible 
> that the link is not part of the flooding topology (e.g. one of the multiple 
> links between two nodes), it might be optimal if we can figure it out and 
> save recalculation here.


This comment isn’t specific to this algorithm, so you’ll pardon me if I jump in.

Always recomputing the flooding topology is always a safe thing to do and for 
the case of a distributed algorithm is probably the safest design choice.

Doing the analysis about the change is not exactly trivial and computing the 
flooding topology is not that hard.  We are typically not short of CPU cycles 
and recomputing the flooding topology is outside of the critical convergence 
window, so while there is some theoretical benefit, it’s not at all clear that 
it’s of great practical benefit.  But it is up to those specifying the 
algorithm.

Regards,
Tony



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


[Lsr] Request for Working Group Adoption: Area Proxy

2020-06-04 Thread tony . li

Dear Gentlebeings,

I would like to formally request working group adoption of “Area Proxy for 
IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03 
).

The goal of this work is to improve scalability of IS-IS when transit L1 areas 
are in use.  In legacy IS-IS, for the L1 area topology to be utilized by L2, 
part of the topology must be configured as both Level 1 and Level 2. In the 
case where the transit topology is most or all of the L1 area, this creates a 
scalability issue as the size of the L2 LSDB approaches that of the entire 
network.

We propose to address this by injecting only a single LSP into Level 2. We call 
this the Proxy LSP and it contains all reachability information for the L1 area 
plus connectivity from the L1 area to L2 adjacencies. The result is that the L1 
area is now opaque, reachable, and fully capable of providing L2 transit.

Our use case is the deployment of Clos topologies (e.g., spine-leaf topologies) 
as transit nodes, allowing these topologies to replace individual routers. We 
also see applications of this approach to abstract entire data centers or POPs 
as single nodes within the L2 area.

There are two other proposals of note before the working group.

In Topology Transparent Zones 
(https://tools.ietf.org/html/draft-chen-isis-ttz-08 
), an area (or zone) may be 
represented by a single node or as a full mesh of tunnels between the edges of 
the zone. In addition, there is a mechanism to attempt to seamlessly enable and 
disable the effectiveness of the zone. Relative to our proposal and for our use 
cases, the full mesh of tunnels is not as effective at providing scalability. 
In the specific case of spine-leaf networks, the leaves are typically the 
majority of the nodes in the network. As they become the edges of the area, 
with the full mesh approach, the majority of the area is not abstracted out of 
the L2 LSDB. For our use case, we have concerns about enabling and disabling 
the abstraction mechanism. There is added complexity to support this mechanism. 
In networks at scale, disabling abstraction may cause scalability failures. 
Enabling abstraction may cause failures as LSPs age out at dissimlar times. We 
feel that establishing abstraction is fundamental to the architecture of the 
network and that changing it on the fly is a highly risky operation, best 
suited for maintenance windows. Accordingly, the additional complexity of the 
transition mechanism is not required.

In IS-IS Flood Reflection 
(https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 
), 
abstraction is achieved by mechanisms similar to ours, but transit service is 
achieved by tunneling transit traffic. That’s not necessary in our propsal.  In 
Flood Reduction, the also is coupled to the flooding reduction, whereas in our 
proposal, the two are independent, tho they do share the Area Leader mechanism.

While both of these proposals are very worthy, we believe that our proposal has 
substantial merit. We ask that the WG adopt Area Proxy for further work.

Regards,
Tony & Sarah___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

2020-06-02 Thread tony . li

Hi Loa,

> The code points are requested from "the IS-IS TLV Codepoints registry",
> howver the "IS-IS TLV Codepoints" is a name space with 14 different
> registries. I think the the registry you want to allocated code point
> from the "TLV Codepoints registry”


I apologize for the confusion, you are certainly correct.

The confusion arises because the page is named “IS-IS TLV Codepoints” and the 
registry is the “TLV Codepoints Registry” so to be precise, we should request 
an allocation from the “IS-IS TLV Codepoints TLV Codepoints Registry”.  That 
does seem somewhat awkward and redundant redundant.

To reduce confusion in the future, perhaps the entire page should be renamed to 
“IS-IS Codepoints”?

Regards,
Tony

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


Re: [Lsr] [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

2020-06-01 Thread Tony Li

Hi Amanda,

> However, the IANA Considerations section is missing some information. How 
> would we fill in the IIH, LSP, SNP, and Purge fields for the TLV Codepoint 
> registrations?


We’ve addressed this in 
https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06 
.

Thanks,
Sarah & Tony

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


Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-27 Thread tony . li

Les,


> We are contemplating submitting a draft for this algorithm to the WG.


We would welcome that.  

Does your algorithm have any relationship to 
https://tools.ietf.org/html/draft-allan-lsr-flooding-algorithm-00? 



> [Les:] As I understand it, draft-chen only supports centralized mode – which 
> is why it is Informational track and does not have interoperability concerns.
> Sarah/Tony - do you have plans to extend this to support distributed mode and 
> then standardize it?


Not at this time.  As we said during our presentation, we found debugging this 
already ‘challenging’ and morphing it to be distributed and deterministic in 
distributed mode doesn’t pass our sense of a beneficial cost/benefit ratio.

We have no objections if others want to take this on.  Centralized mode Just 
Works.


> And the point of allowing multiple standardized algorithms to be defined was 
> in the expectation that more than one might be proven useful.


Interoperability might also prove useful. :-)

Tony


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


Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-24 Thread tony . li

Hi Gyan,


> Do you know if the dynamic flooding algorithm discussed during interim ietf 
> by Sarah and Toni is the same as the one implemented by Cisco on Nexus 
> platform or is Cisco’s Dynamic flooding a proprietary implementation?


It appears not to be.  Our algorithm is not limited to leaf-spine topologies 
and has been tested against numerous other dense and sparse topologies.


> Why would we not want to adopt the best algorithm that is best for both full 
> mesh and non full mesh leaf spine topology algorithm that works for all 
> physical topologies and adopt that draft.  


Proving that an algorithm is ‘optimal’ is going to be very difficult, both from 
a theoretical and market standpoint. As is frequently the case with IETF, we 
are proposing many ideas and trying to sort through them.


> Unless a one size fits all won’t work I would like to understand why one best 
> solution draft we come up with for an FT algorithm for all possible physical 
> topologies cannot be picked for WG adoption.
> 
> Why would we want to adopt multiple flooding algorithms?


Adoption does not imply that it will be standardized.  It merely means that 
it’s part of the working group’s effort.  It is up to the WG and the market to 
decide which algorithms we should pursue.  Some may be enhanced, some may be 
revised, and some may be discarded. We can also adopt all of them and let the 
market sort it out.  That’s probably not the optimal approach from a 
technological perspective, but making real decisions in the modern IETF is very 
hard.

Tony


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


Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-22 Thread tony . li

Hi Gyan,

> I think with clos spine leaf the mesh is much more intensive and problematic 
> with ECMP then a circular topology nodal mesh that results in duplicate 
> redundant flooding that slows down convergence.  With spine leaf it’s like an 
> X horizontal width axis and then depth is spine to leaf links.  With spine 
> leaf as you grow sideways and the spine expand the redundant ECMP grows and 
> redundant flooding grows exponentially and is much worse then circular nodal 
> mesh.  

One very nice thing about dynamic flooding is that it computes a flooding 
topology at the node level.  If the adjacency between A and B is on the 
flooding topology, then any single link between them may be used for flooding.  
If you have 128 way parallel links, this is an immediate 128x improvement in 
flooding overhead.  What’s more, A and B do not need to agree on which link 
they are using and can use different links, resulting in an asymmetric 
situation, without any loss of correctness or performance. 

Regards,
Tony

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


Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-20 Thread tony . li

Hi Gyan,


> This is a much needed feature that operators have been needing for densely 
> meshed topologies that commonly exist in data centers to accommodate very 
> high bandwidth E-W traffic.

Thank you.

> Please look at the feature description and it does seem to be exactly the 
> same as this draft.  Please confirm. 


It would appear to be a different, proprietary, and unpublished algorithm.  

This will give us three different implementations, using three different 
algorithms, none of which will inter-operate.  Whee!!! :-(


> There maybe other vendors due to industry demand have to get the feature 
> deployed before it reaches standards vendor consensus with the IETF.


Our implementation shipped last year.


> We are testing this feature and planning to deploy but wanted to ensure that 
> this is the same as the draft on the standards track.


It does not appear to be, but someone from Cisco should confirm.

Tony

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


Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

2020-05-18 Thread tony . li


> On May 15, 2020, at 12:47 PM, Acee Lindem (acee) 
>  wrote:
> 
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
>  


Hi,

Our IPR disclosure for dynamic flooding (https://datatracker.ietf.org/ipr/4044/ 
) may also apply to this draft.

I am not a lawyer and I don’t play one on this mailing list, either.

Regards,
Tony

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


Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

2020-05-11 Thread tony . li

Hi Xuesong,

> Thank you for giving detailed proof, and it is very helpful to understand the 
> mechanism.
> As I understand, it is showed in the proof that if there is proper temporary 
> flooding in R = E - E* - E’, same connectivity could be achieved by the 
> flooding topology F’ just as G’. I agree with this.


I’m glad it helped.


> The problem for me now is how to enable the temporary flooding properly.
> Here is an example:
> 
> The solid line presents the physical link inside flooding topology, and the 
> dashed line presents the physical link out of flooding topology.
> From the view of me, when multipoint failure happens, node 3 is supposed to 
> enable the temporary flooding between 3 and 4, in order to connect with the 
> nodes inside the red box, while the other dashed line between node 1 and node 
> nobody is not supposed to do temporary flooding although node 1 is connected 
> to the failed link directly.
> It seems a little unclear for me about how the node itself could decide 
> whether a dashed line should do temporary flooding or not in this case.


The problem that you’re asking about is partition detection.

To explain this, I’ve taken the liberty of adding some more labels to your 
diagram.

To start, each node has its link state database and the flooding topology.  
Each node should receive link state updates from nodes in its partition, but 
will not receive updates from other nodes, thus the link state database is 
partially inconsistent and must be treated with care.

For example, node 2 will see updates from nodes 1, 6, and 7, informing it of 
the failure, but it will not receive an update from node 8.

Now, the job of each node is try to compute the partitions of the flooding 
topology.  In particular, each node needs to understand which nodes are in its 
partition. A node cannot know all of the partitions that exist, but it turns 
out that that’s irrelevant.

Once a node understands which nodes are in its partition, then it is a simple 
matter to see which links should be enabled for temporary flooding.  If a 
neighbor is in the same partition (e.g., nodes 1 and 5), then adding the link 
adds no value. If the neighbor is not in the same partition (e.g., nodes 3 and 
4), then it becomes a recovery link.

The actual computation of the partitions is straightforward, with one caveat: 
we always want to perform a two-way check for connectivity.  An implementation 
should be doing this during SPF already, so this should be familiar. The reason 
for doing this is quite clear: in node 2’s link state database (LSDB), the LSP 
for node 8 will show connectivity to node 1 even after the failure. However, 
node 1’s LSP will clearly show that the adjacency has failed.  We can only 
infer connectivity when we see both sides of the adjacency are up.

Given this, the specific algorithm that you choose is an implementation detail. 
 You could do a breadth-first search or a depth-first search. Our 
implementation chooses to walk the entire flooding topology, building a tree of 
the partitions that it detects. [IPR note: we have a IPR claim for this 
approach, with the “don’t sue us, we won’t sue you” terms.]

I hope this helps.

Regards,
Tony


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


Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

2020-05-09 Thread tony . li

Hi Xuesong,


> Thank you for your work about Flooding Reduction mechanism. I think it is 
> very useful for IGP scalability.


Thank you, we very much appreciate that.


> When Sarah giving presentation for 
> draft-chen-lsr-dynamic-flooding-algorithm-00 in LSR interim meeting, I raised 
> a question about how to handle multipoint failure in the flooding topology. I 
> remembered that draft-ietf-lsr-dynamic-flooding-04 was mentioned. I have read 
> this draft, especially section 6.8.11 and temporary flooding relevant 
> content. I think it is a valid method logically. (We have tried to raise some 
> examples to challenge this method, but in all these cases, this method works) 
> Considering that reliability of IGP is crucial for deployment, we are still 
> wondering whether some mathematical proof is necessary (or possible) to 
> guarantee that, in all the possible scenarios, proper convergence could be 
> achieved when using flooding reduction algorithm, just as traditional IGP 
> mechanism. The proof may be case by case depending on the flooding reduction 
> algorithm, but we think even some example or clue about how to do this will 
> be very helpful.


A proof? Ok, I can try to be rigorous, but it’s been a very long time. I 
apologize in advance to Kireeti, Mr. Myers, Mr. Douglas, and Prof. Greever for 
what follows.


Definition: Let G=(V, E) be a finite graph. F=(V, E’) is a ‘flooding topology’ 
on G if E’ is a subset of E and F is connected.


We normally have other properties for flooding topologies, such as being 
bi-connected, relatively sparse, minimal diameter, and minimal degree, but 
those properties are not relevant for this proof.


Definition: Let C=(V*, E*), V* a subset of V, E* a subset of E, be the ‘cut’ of 
G. This represents the failures in the topology. Let G’ = G - C, the topology 
after failure, and let F’ = F - C, be the flooding topology after failure. 


Definition: Let R = E - E* - E’. This is the set of 'recovery edges': edges 
that have not failed and are not part of the flooding topology.


Corollary: R is finite. 

Proof: G is finite, by definition. Therefore E is finite, E* must be finite, 
and E’ is finite.


Lemma 1: If G’ is connected, then F’ + R is connected.

Proof: 

G’ = G - C = (V, E) - (V*, E*) = (V - V*, E - E*).  

F’ + R = (F - C) + (E - E* - E’) = (V, E’) - (V*, E*) + (E - E* - E’) = ( V - 
V*, E’ - E* ) + ( E - E* - E’) = ( V - V*, E’ - E* + E - E* - E’ ) = ( V - V*, 
E - E* - E* ) = ( V - V*, E - E* ) = G’.

Q.E.D.


Lemma 2: If G’ is connected, then incrementally adding edges from R to F’ will 
yield a connected flooding topology.

Proof: By induction. Let R’ be a subset of R. Induction property: Either F' + 
R’ is connected, or R’ is a proper subset of R.

Base case: R’ is the empty set. If F’ is connected, then F’ + R’ is connected 
and the property is satisfied. If F’ + R’ is not connected, R’ is empty, which 
is a proper subset of R.

Induction case: Let r be a recovery edge in R - R’ (i.e., a new edge to add).  
If F’ + R’ is connected, then the property is satisfied already. If F’ + R’ + r 
is connected, the property is satisfied. If R’ + r = R, then by Lemma 1, the 
property is satisfied. Otherwise, R’ + r != R, and the property is satisfied. 
By our corollary, the induction must terminate.

Q.E.D.



Bugs, questions, and comments are welcome.

Regards,
Tony

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


Re: [Lsr] Flooding across a network

2020-05-07 Thread tony . li

Les,

 
> I have specifically used an example where “microloop avoidance” is not 
> applicable. So I did not want to use the term “microloop” but rather used 
> “loop” so as not to suggest that “microloop avoidance” is a potential 
> solution for the sub-optimal behavior.
> Hope you can appreciate that point.
>  
> It would be easy enough to include more nodes in the topology which only 
> support slow flooding. The end result would be the same.
> I have kept the example simple in the hopes we could more easily agree that 
> what I describe can happen when not all nodes support faster flooding – which 
> is the only point I am trying to make. Whether the ratio of Fast/Slow nodes 
> is large or small or about the same doesn’t eliminate the possibility that 
> the same behavior could be seen – though it might alter the location of the 
> topology change which would be problematic.
>  
> From an operator’s POV, I am pretty sure that what you really care about is 
> whether packets get successfully forwarded or not. I am demonstrating that it 
> isn’t safe to assume forwarding behavior will be optimal when not all nodes 
> support fast flooding.


Your point is well-made. There are certainly going to be topologies where 
making flooding faster would result in worse behavior.

However, the point is that there are also topologies where flooding faster 
would improve convergence. To support those, we must have faster flooding. 
Please focus on that goal.

Regards,
Tony


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


Re: [Lsr] Congestion (flow) control thoughts.

2020-05-07 Thread tony . li

Hi Xuesong,

> I agree that "minimal flooding time " is a good choice, which may differ from 
> the traditional cc in layer 4, which is difficult to get the completion time 
> for each flow.
> I am still a little confused about " fast brand X needs to not overrun slow 
> brand Y while performing well with fast brand Z". Is this talking about 
> interoperation between different company device, which may use different type 
> of cc mechanism?


Yes, I’m talking about interoperability. 

Normally, in this working group, interoperability implies that each 
implementation is sending and receiving correctly formatted packets and 
computing correctly. This particular item adds in one other degree of 
complexity: timeliness. An implementation must be able to go fast or slow, 
depending on the needs of the receiver.

Tony

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


Re: [Lsr] Congestion (flow) control thoughts.

2020-05-06 Thread tony . li

Hi Xuesong,

>  I think there is no need to distinguish the concept of flow control 
> and congestion control, considering that the core idea is the same: monitor 
> the sending rate to match the capability of the bottleneck, no matter there 
> are competitors or not. And the control loop is necessary in both case. 


This matches my perspective.


>  Thank you for explaining about the bottleneck of flooding and 
> different cc solutions that are under discussion. It is helpful and I will 
> read the drafts. 
> There is still one more question left in the previous email: " What is the 
> criteria of comparing different solutions?". I think this is crucial for 
> further discussion and comparative tests. I notice that in Bruno's data, some 
> parameters are mentioned, such as " Duration"," LSP/second"," avg inter-LSP 
> delay", "retransmission time". I'm wondering whether it is able to choose a 
> better solution through these parameters. If not, what should be added or 
> considered. (Some other issues are also considered when choosing cc mechanism 
> in layer 4, such as: fairness among flows, co-existence with other cc 
> mechanism .. )


Sorry for missing the question. The criteria are, I think, quite clear: 
minimize overall flooding time.  As Bruno’s figures show, that does NOT happen 
simply by transmitting at the maximum rate. That causes overruns, resulting in 
retransmissions and that ends up being quite slow (tho we can work on that 
too). The question then is: what control mechanisms do we put in place to 
ensure minimal flooding time? This needs to interoperate across the full 
spectrum of implementations: fast brand X needs to not overrun slow brand Y 
while performing well with fast brand Z.

The floor is very much open.

Tony

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


Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread tony . li

Mitchell,

>   I think we/you are looking at two different problems: 
> 1) a hop count of 1 or maybe two between the two end points 2) and the 
> multiple / many hop count between the two end points.


IS-IS adjacencies are always between immediate L3 neighbors, ignoring strange 
things like tunneling.


>   Thus, I think that your issue is mostly the #2 problem 
> and the problem that most CA algorithms IMO always try to increase capacity 
> and thus at some point must exceed capacity. TCP must find a range of 
> capacity per flow (assuming a consistent a number of packets per sec). 
> However, what is maybe missed (I missed it in the document) is the ability 
> not to overshoot the TCP threshold point and trigger multiple initial 
> congestion events in/exiting the slow-start phase.


Modern router designs have interface bandwidths from 10-400Gb/s.  The CPU would 
be hard pressed to supply 1Gb/s, therefore for most of the circumstances that 
we’re concerned about, the link capacity is never the issue.

Tony

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


Re: [Lsr] Congestion (flow) control thoughts.

2020-04-30 Thread tony . li

Hi Xuesong,

> In congestion control of layer 4, it is assumed that there is a bottleneck in 
> the network, and the ideal rate of the transmitters equals to a fair share of 
> the bandwidth in the bottleneck. The flows in the network change all the time 
> and so as to the ideal transmitting rate. There are some methods to detect 
> the bottleneck, for example detecting packet loss, setting ECN, RTT and so 
> on. Considering that the goal of cc is to maximize the throughput and 
> minimize the queuing delay, the throughput and delay could be used to compare 
> different cc algorithms.


I consider flow control and congestion control to be separate, but similar 
problems.

Flow control is about creating a single control loop between a single 
transmitter and single receiver.

Congestion control is about creating multiple interacting control loops between 
multiple transmitters and multiple receivers.


> The problem of mine is that for CC of ISIS flooding, where is the 
> bottleneck?(maybe the receiver capability) What method of detecting could be 
> used? (In my understanding, we have two options at this stage: one from the 
> receiver side and the other from the transmitter side) What is the criteria 
> of comparing? (still a little confusing for me )


In the case of modern IS-IS, we have gigabit links everywhere, the bandwidth 
greatly exceeds our needs, and flooding only happens between peers, so link 
resources are never the issue.  Thus, to my mind, congestion only happens when 
a node is engaged in flooding on multiple interfaces concurrently. Effectively, 
congestion control can be seen as flow control with shared resources, or as 
flow control with varying resources.

The resources of concern vary depending on the internals of both the sender and 
receiver.  Some that come to mind are:

- CPU. Both transmitter and receiver have finite cycles available. This is 
typically shared across multiple interfaces, so can congest.

- Process level buffer space. There may be a fixed number of packet buffers 
within the IS-IS process.  These can be depleted.

- Kernel buffers. 

- Internal control fabric. In some multi-chassis designs, the line card chassis 
is remote from the CPU running IS-IS. The network between the two can congest.

- Line card CPU. Again in the case of a multi-chassis system, control packets 
may flow through a CPU on the line card.  This can congest due to cycles or 
buffers.

- Forwarding plane buffers. Modern design for many systems has a forwarding 
plane ASIC doing a great deal of our packet handling. 
  One of its responsibilities is to extract control plane traffic from incoming 
traffic and pass it upwards. As a single ASIC, it is finite and can only buffer
  so many packets before loss.  The buffers are only cleared when the packets 
are read out by the line card or central CPU.  IMHO, this is a very likely 
point of congestion.

All of these can be instrumented to determine whether they are congesting.  It 
seems very unlikely that the transmitter ever congests.  Bruno’s data as 
presented supports this: the transmitter can outstrip the receiver. Thus, we 
tend to focus on congestion at the receiver.

The other feedback mechanisms that we have available are the ones that we’ve 
discussed: PSNPs provide acknowledgment of received packets. From that, and 
their timing, we may be able to infer more useful data, but we are discussing 
changing their behavior to make things more useful.

In our draft, we are proposing other feedback mechanisms.

Tony


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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li

Robert,

> Apologies if I missed it but so far I understood that the new signalling from 
> the receiver could be different per each LSP sender (per each Hello). 


Correct.  We propose to piggyback feedback information in IIH’s, and *SNPs.


> Above I am suggesting that such signalling to be "global" per receiver 
> (ie.sent identical to all LSP senders) under moments of stress/congestion. 


How does that help?

Also, in systems where the area multiple forwarding plane silicon instances, 
the resources for two different interfaces may have very different control 
plane resources available.  A single response would not allow the receiver to 
accurately describe his situation.

Tony


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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li

Robert,

> For per peer flow control I do not get how receiver's ISIS process is to come 
> up with per peer timer if it may never see under congestion given peer's LSPs 
> (being dropped on the single RE cp queue or at the interface). 


I’m sorry, but I can’t parse this comment.  The intent is not for the receiver 
to specify a timer value.  The point is for the receiver to provider the LSP 
sender with feedback about available resources on the receiver. This can inform 
the sender’s computation of a reasonable transmit bandwidth.


> Perhaps such flag to "slow down guys" could be send by receiver uniformly to 
> all peers when under LSP flooding congestion ?


That’s effectively what we’re proposing, tho it need not be a binary flag.  It 
allows us to do simpler things saying “we’re running out of buffer space, 
please slow down a bit”. Again the goal is to find the optimal goodput.  
Granularity in the feedback will be helpful.

Tony


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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li

> If we have 1000 of interfaces and all peers *all in the same time* will send 
> us an LSP of max size of 1492 octets that our control plane buffer RAM size 
> required to store them would be as huge as 1.5 MB. And that assumes we did 
> not process any from arrival of the first to the arrival of the last one. 


And that’s only one LSP.  If they don’t stop there and each sends 1000 LSPs, 
then you can have 10^6 incoming packets, requiring 1.6GB.

Further, since the bottleneck is likely the queue of packet on the forwarding 
chip(s) to the CPU, this 1.6GB needs to exist on the forwarding silicon.  
Needless to say, it doesn’t.

Yes, the CPU can probably keep up with one of the peers. This implies that the 
forwarding plane queue grows at the rate that 999 peers are sending at. Thus, 
congestion.

Tony

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li

Hi Robert,

> Today from what I see operators (if they even change the default) normally 
> apply same timer value on all interfaces. If the timer is static what would 
> be the incentive for any implementation not to group interfaces with 
> identical transmit delay ? 


Why should the timer be static in an optimal system?  We want to avoid the need 
for the timer and have systems be adaptive.


> While this thread is very interesting I must observe that from my experience 
> the issue is usually on the receiver. If LSR would publish a one page 
> draft/rfc mandating that links state packets MUST or SHOULD be recognized and 
> separated from any other control plane traffic at the ingress interface level 
> (on their way to local RE/RP) we likely wouldn't be having such debate. 
> 
> Slowing senders just due to bad implementation of the receiving router is 
> IMHO a little suboptimal (not to say wrong) thing to do. 


Heck, we can do better than that: we can outlaw bad implementations of 
anything.  Do you think that will help? 

The fact of the matter is that even good implementations can congest.  As 
silicon continues to scale, the ratio of interface bandwidth to control plane 
processing power continues to shift. Silicon has completely taken over our 
forwarding planes and scales upwards, where a single chip is now forwardinging 
for hundreds of interfaces. Meanwhile, buffering is finite and control planes 
really can’t keep up. Forwarding is a parallel activity. The control plane is 
not.  This presents us with a situation where congestion is pretty much 
inevitable. We need to deal with it.

Tony

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread tony . li

Robert,

> > In both cases, this call, IMO a signaling capability from the receiver to 
> > the sender.  
> 
> So essentially you are asking for per peer flooding queue. 


You already have a per-interface flooding ‘queue' through the implementation of 
the SRM bit in the LSDB, which must be managed on a per-interface basis.


> Now this get's a little bit of tricky (especially if you are dealing with 
> relatively small timers) if one peer sends you 1 ms, second 50 ms and 10th  
> 250 ms. 


If the peers are on the same interface, then you clearly have to not overrun 
the slower peer.  Note that both are slower than the currently mandated 33ms.

If the peers are on different interfaces, then this tells you how to configure 
the per-interface timers.


> Imagine that the LSP to be flooded to the 10th peer is already overwritten 
> due to new LSP but still sitting in the out queue ... do you drain that queue 
> and start over with new LSP or you in place replace the old one keeping the 
> running timer ? 
> 
> I am just curious what will happen under the hood :) 


You’re assuming a strict queue, when in fact, what happens under the hood is 
simpler: each LSP has a per-interface bit saying that it must be sent on that 
interface. When it’s time to transmit you walk the LSDB looking for an LSP with 
the bit set, and then transmit it. If an LSP is overwritten, that’s fine, the 
bit is still set and you would send the newer version.

Walking the LSDB every time is obviously inefficient, so an implementation is 
free to maintain other data structures to optimize this if it chooses, but the 
semantics are quite clear: send LSPs that haven’t been sent yet.

Regards,
Tony

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed -- A plea for cooperation

2020-04-20 Thread tony . li

Gentlebeings,

This discussion is producing far more heat than light.  Can we please refocus 
our attentions?

I think that we all agree that the legacy parameters are no longer serving us 
well and that we need to reconsider our flooding parameters and mechanisms.

If we fail to reach a constructive consensus, we will end up with a protocol 
that severely underperforms, hurting our end user experience and allowing other
protocols to supplant what we’ve worked so hard for. It behooves us to all work 
together to find a common ground that allows all implementations to 
converge rapidly.

At this point, arguing back and forth does not seem to be helping.

Our goal is to enable rapid flooding of a large LSP database. We need everyone 
to be able to do this. While it may help an implementation to be 
rapid when operating with just itself, in today’s industrial environment, not 
being able to do this across implementations is not helpful. We need
all implementations to be able to be performant.

We have iterated on the points of the discussion repeatedly. Further repetition 
is not helpful. What is lacking is experimentation and facts. 
We need the results of running code. Packet traces with analysis of flow 
control mechanisms. Demonstrations of how particular parameters and
mechanisms perform across implementations and across hardware platform classes. 
Comparisons of our flooding mechanisms with the throughput 
of other transport protocols.

What is going to help all platforms be their best?

Don’t just tell us what you think: prove it.

The competition is not the other implementation. It is other protocols who will 
supplant everything.

Regards,
Tony

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-20 Thread tony . li

Bruno,

> Waiting some more details, as per you below email, the IS-IS receiver does 
> have a queue, sometimes dedicated to IS-IS, but in general relatively 
> dedicated to very important and time sensitive traffic to the control plane. 
> Details are indeed implementation specific. But in general, this queue is 
> designed to protect the IS-IS traffic from lower priority traffic, e.g. 
> burstyBGP.. So can we assume that the receiver have (or at least may have) 
> such a queue, and work with this?


That would be ideal, but probably not realistic. Not all implementations are 
going to have separate queues for BGP and IS-IS.

IMHO, that’s a very good thing, of course, but not all merchant silicon is 
quite that sophisticated. Yet. And it takes years to change, so it’s best that 
we proceed without.

Tony

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


Re: [Lsr] I,Scope of FIT Capability: a node or a link?

2020-04-06 Thread Tony Li


> This discussion is interesting, but please do not ignore the considerable 
> feedback from multiple folks indicating that this advertisement does not 
> belong in the IGP at all (regardless of scope).
> My opinion on that has not changed.


+1

IS-IS is not the correct place to implement Service Discovery mechanisms. The 
management plane already has ample mechanisms for service and capability 
discovery.

Tony


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


Re: [Lsr] Dynamic flooding path computation

2020-04-03 Thread tony . li



Hi Peter,


> it may be worth to make your algorithm one of the standardized distributed 
> algorithms. There might be some work to make it deterministic, like the 
> selection rules mentioned below, but it should be doable.
> 
> What do you think?


I will certainly stipulate the possibility.

However, as I’ve said from the start, I have some grave concerns about 
debugging this and making it inter-operable. Every node choice, every edge 
selection, from the selection of the initial node, through DFS, through BFS, 
needs to be identical. The weighting between degree and diameter needs to 
deterministic and fixed.

We would have to have extensive deployment experience before I would feel 
comfortable pouring concrete on this.

So, if someone would like to make a distributed version, we will support it.  
But we aren’t in a place where we’re ready to drive that effort. Please feel 
free.

Tony

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


Re: [Lsr] On collaboration for abstraction

2020-04-03 Thread tony . li


Hi Alvaro,


> Having official and open meetings is the way to go.


I concur.


> An alternative would be for the group to work as a Design Team: the 
> discussions can happen in the lsr list, periodic open calls can be 
> scheduled...without some of the administrative overhead.  The DT could 
> include others (non-authors) for moderation and coordination, and 
> anyone/everyone would be able to participate.


I have some concerns about how this would be perceived. A Design Team is 
traditionally a small subset of the WG, with intentionally bounded membership. 
Describing this as a Design Team would seem to give the wrong impression and I 
would feel uncomfortable participating in this without lawyers present.

Tony


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


[Lsr] Dynamic flooding path computation

2020-04-02 Thread tony . li

Hi,

In this morning’s session, Acee asked a question about node selection as part 
of path computation.  I would like to expound a bit in the spirit of full 
transparency.

First off, the selection of nodes is NOT vital to the algorithm.  That said, we 
found that applying some heuristics helped make the algorithm slightly more 
efficient in some cases.

We select the starting node for the first cycle (n0 in the slides) by picking a 
node with the highest possible degree in the base topology.  Ideally, we’d 
really like to pick the node that’s at the center of the graph (and to be very 
precise, a node in the centroid or Jordan center), but the computation of this 
is somewhat expensive and doesn’t seem worthwhile.  

At the end of the first cycle, we now have a set of bi-connected nodes that 
each have a degree of 2 in the flooding topology.  We could start the next 
iteration with any of these nodes, but we already know that n0 has the highest 
degree of anything in the topology, so we can always start the next iteration 
based off of n0.  Note that we do NOT want to continue doing this for 
subsequent iterations because the degree of n0 would quickly spiral out of 
control.  Instead, we want to continue to bound the degree of the nodes in the 
flooding topology, so we want to select a node that is on the flooding 
topology, but minimizes both degree and diameter.  Again, we are not trying for 
optimality, so we apply a simple weighting function to aid in this selection.

I hope this makes our approach very clear.

Regards,
Tony

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


Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread tony . li

> Sure it is possible to discover if my tailends are capable of handling in 
> band telemetry by off line means. But what I am struggling to see why we 
> allowed so much TE stuff into IGPs and we do not want to make it easier for 
> headends to operate without PCE at all for the purpose of delivering such 
> type of services. 


AFAICT, we put a lot of effort into making headend path computation useful and, 
for the most part, it was and is not necessary.

Even with legacy mechanisms, people decided that they need global optimization 
and that head-end path computation was Not That Interesting.

It’s now 20 years later, the network is even more dynamic, the expectations 
about response time are that much higher, and concerns about link state 
database stability and scalability have increased.  Modern telemetry is 
definitely not suitable to be passed in the IGP anymore.  

Thus, it seems like the IGP can provide base topology information and traffic 
engineering constructs should leverage that and provide an independent 
telemetry collection plane. Within that plane, telemetry capabilities can and 
should be confined to the telemetry plane.

As we’ve said many times before: BGP is not a dump truck. Analogously, the IGP 
isn’t even an SUV.

;-)

Regards,
Tony

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


[Lsr] On collaboration for abstraction

2020-04-02 Thread tony . li

Hi,

I’d like to comment on the process for moving forward for the abstraction 
proposals that we are discussing (TTZ, Area proxy, flooding reduction, …).

My understanding of the block on collaboration is that we are prohibited from 
collaborating privately.  We MAY have open, public discussions.

Thus, I would propose that we have more interim meetings to try to progress 
this issue.  To help ensure that these are truly public, I believe that the WG 
chairs should coordinate and moderate these meetings.

It is legally important that there be no side discussions. At all.

Thoughts?


Regards,
Tony

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


[Lsr] Fwd: New Version Notification for draft-chen-lsr-dynamic-flooding-algorithm-00.txt

2020-03-03 Thread tony . li


Hi,

We have submitted a draft that describes the Arista algorithm for computing 
flooding topologies.

This draft is informational and we are not proposing that this transition to 
the standards track.
If the working group chooses to do further work based on this, we have no 
objections.

Regards,
Sarah & Tony



> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for 
> draft-chen-lsr-dynamic-flooding-algorithm-00.txt
> Date: March 3, 2020 at 10:16:37 AM PST
> To: "Yunxia Chen" , "Tony Li" , "Sarah 
> Chen" 
> 
> 
> A new version of I-D, draft-chen-lsr-dynamic-flooding-algorithm-00.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-chen-lsr-dynamic-flooding-algorithm
> Revision: 00
> Title:An Algorithm for Computing Dynamic Flooding Topologies
> Document date:2020-03-03
> Group:Individual Submission
> Pages:9
> URL:
> https://www.ietf.org/internet-drafts/draft-chen-lsr-dynamic-flooding-algorithm-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/
> Htmlized:   
> https://tools.ietf.org/html/draft-chen-lsr-dynamic-flooding-algorithm-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-chen-lsr-dynamic-flooding-algorithm
> 
> 
> Abstract:
>   Link-state routing protocols suffer from excessive flooding in dense
>   network topologies.  Dynamic flooding [I-D.ietf-lsr-dynamic-flooding]
>   alleviates the problem by decoupling the flooding topology from the
>   physical topology.  Link-state protocol updates are flooded only on
>   the sparse flooding topology while data traffic is still forwarded on
>   the physical topology.
> 
>   This document describes an algorithm to obtain a sparse subgraph from
>   a dense graph.  The resulting subgraph has certain desirable
>   properties and can be used as a flooding topology in dynamic
>   flooding.
> 
>   This document discloses the algorithm that we have developed in order
>   to make it easier for other developers to implement similar
>   algorithms.  We do not claim that our algorithm is optimal, rather it
>   is a pragmatic effort and we expect that further research and
>   refinement can improve the results.
> 
>   We are not proposing that this algorithm be standardized, nor that
>   the working group use this as a basis for further standardization
>   work, however we have no objections if the working group chooses to
>   do so.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-20 Thread Tony Li

Les,

> With respect, it is hard to know what you are proposing since there has never 
> been a public description.

With respect, I’ve said it many times, both in person and in email. You need to 
hear it again? Sure.


> The draft on which you are a co-author does not discuss any sort of algorithm 
> to dynamically alter the advertised value based on current router state. In 
> fact it argues (or at least suggests) that this shouldn't be done.


I’m suggesting being more dynamic than what that draft advocates.

> Apparently you have a different idea, which maybe the next version of 
> draft-decraene will include, but right now all we have as a description is a 
> series of isolated sentences in multiple emails. You'll have to forgive me if 
> I am not always clear about what you intend but have yet to state.

Again, what I’m suggesting is that the LSP receiver use a TLV (possibly 
Bruno’s, possibly tweaked) to tell the LSP transmitter the current space in the 
input packet queue. As previously described, we may want to consider 
oversubscription when advertising this value. This MAY be included in IIH’s and 
SNP’s, piggy backed on existing transmissions. 

The LSP transmitter MAY use this information, in conjunction with the knowledge 
of unacknowledged LSPs, to optimize the transmission rate. If no information is 
learned from the LSP receiver, the LSP transmitter is no worse off. If the 
information that was learned is old, then LSP transmitter is free to ignore it.

If the LSP receiver can’t provide a useful value (e.g., if the PD layer hasn’t 
been implemented), it is free to provide either the static value or no value.

As always, I am expecting that implementation experience and inter-operability 
testing will contribute to this effort, and I am not expecting the right answer 
in the first pass.

Tony

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread tony . li


> easy to say with a single PD. If you have 20, each with a different 
> architecture, it becomes a different problem.


My employer has multiple PD implementations. I sympathize, but it’s still 
necessary.

Tony

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread tony . li


Les,

> As you need to send signaling based upon dynamic receiver state and this 
> signaling is contained in unreliable PDUs (hellos) and to be useful this 
> signaling needs to be sent ASAP - you cannot wait until the next periodic 
> hello interval (default 10 seconds) to expire. So you are going to have to 
> introduce extra hello traffic at a time when protocol input queues are 
> already stressed.


I am not proposing that we add additional packets at this time.  Yes, I realize 
that it may limit the effectiveness of the feedback, but without serious 
experimentation, the cure may be worse than the disease.  I propose to tread 
very carefully.


> Given hellos are unreliable, the question of how many transmissions of the 
> update flow info is enough arises. You could make this more deterministic by 
> enhancing the new TLV to include information received from the neighbor so 
> that each side would know when the neighbor had received the updated info. 
> This then requires additional hellos be sent in both directions - which 
> exacerbates the queue issues on both receiver and transmitter.


I am not proposing this.  If the hello is lost, then the transmitter has less 
information to work with, which is not an unreasonable situation.

Tony

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread tony . li

Peter,

> I'm not scared of polynomial evaluation, but the fact that my IGP 
> implementation is dependent on the PD specifics, which are not generally 
> available and need to be custom built for each PD specifically. I always 
> thought a good IGP implementation is PD agnostic.


Your implementation is always dependent on the underlying hardware.  We have 
timers, we have filesystems, we have I/O subsystems, threads, and clocks to 
contend with. The input queue in the hardware is a fact of life and knowing 
about it can improve our implementations.

Because the PD layer can provide isolation from the specifics, the IGP 
implementation is reasonably abstracted from those specifics, in much the same 
way that the OS has abstracted us from the remainder of the underlying 
hardware. All I’m proposing is adding one more item to that PD abstraction.

Regards,
Tony

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread Tony Li

Peter,

> I'm aware of the PD layer and that is not the issue. The problem is that 
> there is no common value to report across different PD layers, as each 
> architecture may have different number of queues involved, etc. Trying to 
> find a common value to report to IPGs across various PDs would involve some 
> PD specific logic and that is the part I'm referring to and I would like NOT 
> to get into.


I’m sorry that scares you.  It would seem like an initial implementation might 
be to take the min of the free space of the queues leading from the interface 
to the CPU. I grant you that some additional sophistication may be necessary, 
but I suspect that this is not going to become more complicated than polynomial 
evaluation. 

Tony

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


Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread Tony Li


Peter,

> Given many different hardware architectures one may run a single IGP 
> implementation on, this becomes impractical and complex as each hardware 
> architecture has its own specifics. One would rather keep the IGP 
> implementation hardware agnostic, rather than providing hardware specific 
> hooks for each platform it runs on.

This is why your software architecture has a Platform Dependent component. This 
is a service that you should require from the PD layer.

Tony

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


  1   2   3   >