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

[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

[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] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Gyan Mishra]

Agreed that Rift negative  disaggregation and PUA proposed are  in no way
comparable.   Sorry to make that analogy but unfortunately it was the first
thing that came to mind when reading the draft.

I was I will work with Aijun to help fill the gaps & points noted in this
thread  without adding more complexity.

>From an operators perspective I agree backwards compatibility is
requirement.

Kind Regards

Gyan

On Fri, Sep 4, 2020 at 4:03 PM Acee Lindem (acee)  wrote:

> Speaking as WG member….
>
>
>
> This is in no way comparable. This solution presented in the draft is full
> of holes and non-backward compatible. The problem may be solvable but the
> question is whether or not the required complexity is  worse than a problem
> that could be solved with proper network design.
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *"Les Ginsberg (ginsberg)" 
> *Date: *Friday, September 4, 2020 at 3:00 PM
> *To: *Tony Przygienda , Aijun Wang <
> wangai...@tsinghua.org.cn>
> *Cc: *Gyan Mishra , Robert Raszuk <
> rob...@raszuk.net>, Huzhibo , Aijun Wang <
> wang...@chinatelecom.cn>, Peter Psenak ,
> lsr , Acee Lindem , Xiaoyaqun <
> xiaoya...@huawei.com>
> *Subject: *RE: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> In support of what Tony has said, I think any comparison between what RIFT
> is doing and what is proposed in this draft is inappropriate.
>
>
>
> RIFT is able to determine what destinations exist in the network but are
> not reachable via a certain subset of the topology – and then generate
> negative advertisements appropriately. There is also full determinism in
> knowing when the negative advertisement should be removed.
>
>
>
> draft-wang-lsr-prefix-unreachable-announcement by contrast tries to
> provide an advertisement for a destination that no longer exists. This
> leads to the lack of determinism which necessitates arbitrary timers and
> creates problems for nodes who connect to the network after the
> disappearance of the destination.
>
>
>
> Not comparable at all IMO…
>
>
>
>Les
>
>
>
> *From:* Lsr  *On Behalf Of *Tony Przygienda
> *Sent:* Friday, September 04, 2020 11:12 AM
> *To:* Aijun Wang 
> *Cc:* Gyan Mishra ; Robert Raszuk <
> rob...@raszuk.net>; Huzhibo ; Aijun Wang <
> wang...@chinatelecom.cn>; Peter Psenak ;
> lsr ; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> I read the draft since the longish thread triggered my interest. As Peter
> said very thin ice walking with magic soft-state-timers for (to me)
> entirely unclear benefit and lots of interesting questions completely
> omitted like e.g. what will happen if a mix of old and new routers are in
> the network.
>
>
>
> RIFT works completely differently BTW (and I don't think we _also_ noticed
> the problem, AFAIK RIFT is the first protocol that defined the concept of
> at least negative disaggregation to deal with black-hole avoidance in
> presence of summaries). RIFT defines precisely how negative disaggregation
> state is transitively propagated (if necessary) and next-hop resolved via
> recursive inheritance to provide black-hole and loop free routing in case
> of links failures on IP fabrics. No soft-timers or undescribed magic there.
> However, to do what RIFT is doing a sense of direction on the graph is
> needed (this is relatively easy on semi-lattice RIFT supports but would
> precondition uniform topological sorting on generic graphs, probably ending
> up in RPL type of solutions [which still need a direction indicator on arc
> to work and would take out a lot of links out of the topology possibly {but
> Pascal is better to judge that}]).
>
>
>
> -- tony
>
>
>
> On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
> wrote:
>
> Hi, Gyan:
>
>
>
> Sorry for replying you so late.
>
> You are right about the summary address behavior, but the summary address
> is configured by manually, and if one of the specific prefix within this
> summary range is down, the black hole(route to this specific prefix) will
> be formed.  PUA mechanism just want to amend this.
>
> Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such
> problem needs also be solved.
>
>
>
> If you are interested this topic, welcome to join us to the solution.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan
> Mishra
> *Sent:* Thursday, August 6, 2020 4:44 PM
> *To:* Aijun Wang 
> *Cc:* Peter Psenak ; Robert Raszuk <
> rob...@raszuk.net>; Huzhibo ; Aijun Wang <
> wang...@chinatelecom.cn>; lsr ; Acee Lindem (acee) <
> a...@cisco.com>; Xiaoyaqun 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun and authors
>
>
>
> I am catching up with this thread after reading through this draft.
>
>
>
> I understand the concept that we ar

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Acee Lindem (acee)]

Speaking as WG member….

This is in no way comparable. This solution presented in the draft is full of 
holes and non-backward compatible. The problem may be solvable but the question 
is whether or not the required complexity is  worse than a problem that could 
be solved with proper network design.

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" 
Date: Friday, September 4, 2020 at 3:00 PM
To: Tony Przygienda , Aijun Wang 

Cc: Gyan Mishra , Robert Raszuk , 
Huzhibo , Aijun Wang , Peter 
Psenak , lsr , Acee Lindem 
, Xiaoyaqun 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

In support of what Tony has said, I think any comparison between what RIFT is 
doing and what is proposed in this draft is inappropriate.

RIFT is able to determine what destinations exist in the network but are not 
reachable via a certain subset of the topology – and then generate negative 
advertisements appropriately. There is also full determinism in knowing when 
the negative advertisement should be removed.

draft-wang-lsr-prefix-unreachable-announcement by contrast tries to provide an 
advertisement for a destination that no longer exists. This leads to the lack 
of determinism which necessitates arbitrary timers and creates problems for 
nodes who connect to the network after the disappearance of the destination.

Not comparable at all IMO…

   Les

From: Lsr  On Behalf Of Tony Przygienda
Sent: Friday, September 04, 2020 11:12 AM
To: Aijun Wang 
Cc: Gyan Mishra ; Robert Raszuk ; 
Huzhibo ; Aijun Wang ; Peter 
Psenak ; lsr ; Acee Lindem 
(acee) ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

I read the draft since the longish thread triggered my interest. As Peter said 
very thin ice walking with magic soft-state-timers for (to me) entirely unclear 
benefit and lots of interesting questions completely omitted like e.g. what 
will happen if a mix of old and new routers are in the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed the 
problem, AFAIK RIFT is the first protocol that defined the concept of at least 
negative disaggregation to deal with black-hole avoidance in presence of 
summaries). RIFT defines precisely how negative disaggregation state is 
transitively propagated (if necessary) and next-hop resolved via recursive 
inheritance to provide black-hole and loop free routing in case of links 
failures on IP fabrics. No soft-timers or undescribed magic there. However, to 
do what RIFT is doing a sense of direction on the graph is needed (this is 
relatively easy on semi-lattice RIFT supports but would precondition uniform 
topological sorting on generic graphs, probably ending up in RPL type of 
solutions [which still need a direction indicator on arc to work and would take 
out a lot of links out of the topology possibly {but Pascal is better to judge 
that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Gyan:

Sorry for replying you so late.
You are right about the summary address behavior, but the summary address is 
configured by manually, and if one of the specific prefix within this summary 
range is down, the black hole(route to this specific prefix) will be formed.  
PUA mechanism just want to amend this.
Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such problem 
needs also be solved.

If you are interested this topic, welcome to join us to the solution.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
[mailto:lsr-boun...@ietf.org] On Behalf Of Gyan 
Mishra
Sent: Thursday, August 6, 2020 4:44 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Huzhibo 
mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Xiaoyaqun 
mailto:xiaoya...@huawei.com>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Aijun and authors

I am catching up with this thread after reading through this draft.

I understand the concept that we are trying to send a PUA advertisement which 
sounds similar to Rift Negative Disaggregation prefix now with a  null setting 
when a longer match component prefix that is part of a summary range is down to 
detect prefix down conditions with longer match component prefixes that are 
part of a summary.

Basically how summarization works with both OSPF and ISIS is that at minimum a 
single longer match within the defined IA summary range must exist for the IA 
summary to be sent.  So the summary is sent conditionally similar to a BGP 
conditional advertisement or even a ospf default originate which requires a 
default in the RIB to exist before the adver

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Les Ginsberg (ginsberg)]

In support of what Tony has said, I think any comparison between what RIFT is 
doing and what is proposed in this draft is inappropriate.

RIFT is able to determine what destinations exist in the network but are not 
reachable via a certain subset of the topology – and then generate negative 
advertisements appropriately. There is also full determinism in knowing when 
the negative advertisement should be removed.

draft-wang-lsr-prefix-unreachable-announcement by contrast tries to provide an 
advertisement for a destination that no longer exists. This leads to the lack 
of determinism which necessitates arbitrary timers and creates problems for 
nodes who connect to the network after the disappearance of the destination.

Not comparable at all IMO…

   Les

From: Lsr  On Behalf Of Tony Przygienda
Sent: Friday, September 04, 2020 11:12 AM
To: Aijun Wang 
Cc: Gyan Mishra ; Robert Raszuk ; 
Huzhibo ; Aijun Wang ; Peter 
Psenak ; lsr ; Acee Lindem 
(acee) ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

I read the draft since the longish thread triggered my interest. As Peter said 
very thin ice walking with magic soft-state-timers for (to me) entirely unclear 
benefit and lots of interesting questions completely omitted like e.g. what 
will happen if a mix of old and new routers are in the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed the 
problem, AFAIK RIFT is the first protocol that defined the concept of at least 
negative disaggregation to deal with black-hole avoidance in presence of 
summaries). RIFT defines precisely how negative disaggregation state is 
transitively propagated (if necessary) and next-hop resolved via recursive 
inheritance to provide black-hole and loop free routing in case of links 
failures on IP fabrics. No soft-timers or undescribed magic there. However, to 
do what RIFT is doing a sense of direction on the graph is needed (this is 
relatively easy on semi-lattice RIFT supports but would precondition uniform 
topological sorting on generic graphs, probably ending up in RPL type of 
solutions [which still need a direction indicator on arc to work and would take 
out a lot of links out of the topology possibly {but Pascal is better to judge 
that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Gyan:

Sorry for replying you so late.
You are right about the summary address behavior, but the summary address is 
configured by manually, and if one of the specific prefix within this summary 
range is down, the black hole(route to this specific prefix) will be formed.  
PUA mechanism just want to amend this.
Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such problem 
needs also be solved.

If you are interested this topic, welcome to join us to the solution.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
[mailto:lsr-boun...@ietf.org] On Behalf Of Gyan 
Mishra
Sent: Thursday, August 6, 2020 4:44 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Huzhibo 
mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Xiaoyaqun 
mailto:xiaoya...@huawei.com>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Aijun and authors

I am catching up with this thread after reading through this draft.

I understand the concept that we are trying to send a PUA advertisement which 
sounds similar to Rift Negative Disaggregation prefix now with a  null setting 
when a longer match component prefix that is part of a summary range is down to 
detect prefix down conditions with longer match component prefixes that are 
part of a summary.

Basically how summarization works with both OSPF and ISIS is that at minimum a 
single longer match within the defined IA summary range must exist for the IA 
summary to be sent.  So the summary is sent conditionally similar to a BGP 
conditional advertisement or even a ospf default originate which requires a 
default in the RIB to exist before the advertisement is sent.  A good example 
of non conditional analogy with BGP if you have a null0 static for a summary 
for an exact match BGP advertisement the prefix is always advertised no matter 
what even if no component prefixes exist.  This can result in black hole 
routing. BGP has conditional feature to conditionally advertisement based on 
existence of a route advertisement of downstream neighbor in the BGP RIB.  So 
with ospf and Isis the summary is in fact conditional similar to a BGP 
conditional advertisement and in the example given in the draft in section 3.1 
when node T2 is down and pt2 becomes unreachable and let’s sa

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Tony Przygienda]

I read the draft since the longish thread triggered my interest. As Peter
said very thin ice walking with magic soft-state-timers for (to me)
entirely unclear benefit and lots of interesting questions completely
omitted like e.g. what will happen if a mix of old and new routers are in
the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed
the problem, AFAIK RIFT is the first protocol that defined the concept of
at least negative disaggregation to deal with black-hole avoidance in
presence of summaries). RIFT defines precisely how negative disaggregation
state is transitively propagated (if necessary) and next-hop resolved via
recursive inheritance to provide black-hole and loop free routing in case
of links failures on IP fabrics. No soft-timers or undescribed magic there.
However, to do what RIFT is doing a sense of direction on the graph is
needed (this is relatively easy on semi-lattice RIFT supports but would
precondition uniform topological sorting on generic graphs, probably ending
up in RPL type of solutions [which still need a direction indicator on arc
to work and would take out a lot of links out of the topology possibly {but
Pascal is better to judge that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
wrote:

> Hi, Gyan:
>
>
>
> Sorry for replying you so late.
>
> You are right about the summary address behavior, but the summary address
> is configured by manually, and if one of the specific prefix within this
> summary range is down, the black hole(route to this specific prefix) will
> be formed.  PUA mechanism just want to amend this.
>
> Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such
> problem needs also be solved.
>
>
>
> If you are interested this topic, welcome to join us to the solution.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan
> Mishra
> *Sent:* Thursday, August 6, 2020 4:44 PM
> *To:* Aijun Wang 
> *Cc:* Peter Psenak ; Robert Raszuk <
> rob...@raszuk.net>; Huzhibo ; Aijun Wang <
> wang...@chinatelecom.cn>; lsr ; Acee Lindem (acee) <
> a...@cisco.com>; Xiaoyaqun 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun and authors
>
>
>
> I am catching up with this thread after reading through this draft.
>
>
>
> I understand the concept that we are trying to send a PUA advertisement
> which sounds similar to Rift Negative Disaggregation prefix now with a
>  null setting when a longer match component prefix that is part of a
> summary range is down to detect prefix down conditions with longer match
> component prefixes that are part of a summary.
>
>
>
> Basically how summarization works with both OSPF and ISIS is that at
> minimum a single longer match within the defined IA summary range must
> exist for the IA summary to be sent.  So the summary is sent conditionally
> similar to a BGP conditional advertisement or even a ospf default originate
> which requires a default in the RIB to exist before the advertisement is
> sent.  A good example of non conditional analogy with BGP if you have a
> null0 static for a summary for an exact match BGP advertisement the prefix
> is always advertised no matter what even if no component prefixes exist.
> This can result in black hole routing. BGP has conditional feature to
> conditionally advertisement based on existence of a route advertisement of
> downstream neighbor in the BGP RIB.  So with ospf and Isis the summary is
> in fact conditional similar to a BGP conditional advertisement and in the
> example given in the draft in section 3.1 when node T2 is down and pt2
> becomes unreachable and let’s say that prefix is 1.1.1.1/32 and the
> summary is 1.1.1.0/30 and no other component prefix exists within the
> summary range the prefix will not get adversed.  So there will not be any
> black hole.
>
>
>
> The summary represents all prefixes within the range that would be
> suppressed with the summary when advertised into the backbone area.
> However only at a minimum one prefix must exist in the range for the
> summary to be generated.  That is done by design as the summary represents
> all prefixes within the range.  So let’s say there are a 100 prefixes and
> let’s say a few devices are down and so now only 5 prefixes exist within
> the range.  By design it is OK for router to generate the summary for the 5
> prefixes it is representing and that will not cause any routing loop or
> black hole.
>
>
>
>
>
> I am trying to understand wage gap exists and what we are trying to solve
> related to summarization in the context of IPv6.  Both IPv4 and IPV6
> summarization operates the similarly as far as the requirement of at
> minimum a single component route within the summary range must exist  as a
> condition to be present in the RIB before the summary can be advertised.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On 

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

[bruno.decraene]

Hi Tony,

I may have a comment on 5.2.  Filtering LSP information.
This is old text, but new re-reading.

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


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

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, September 4, 2020 2:29 PM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


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: mailto:i-d-annou...@ietf.org>>
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


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les

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

[bruno.decraene]

Hi Tony,

Please find below some nits/minor comments. Please feel free to silently 
discard.

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.


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.


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

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.

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

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

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

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


Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, September 4, 2020 2:29 PM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


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: mailto:i-d-annou...@ietf.org>>
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 

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

[bruno.decraene]

Hi Tony,

I've read the diff for -03 and -04.
The new encoding of the Area SID is good for me.

And thank you for listening to my use case and suggestion.

Thanks,
--Bruno


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Monday, August 24, 2020 7:02 PM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


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: mailto:i-d-annou...@ietf.org>>
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


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Gyan Mishra]

Hi Aijun

Sure  I would be interested in joining as co-author of the draft.

This an interesting topic as how PUA or negative disaggretion can prevent
black hole routing of summaries when “Longest prefix match” does not exist
due to link or router down event, and how to signal via negative
advertisement PUA to suppress summary advertisement when components
prefixes are not in the rib.

Let me read through the thread and help provide some comments to assist in
progressing the draft.

Thanks

Gyan


On Mon, Aug 24, 2020 at 5:12 AM Aijun Wang 
wrote:

> Hi, Gyan:
>
>
>
> Sorry for replying you so late.
>
> You are right about the summary address behavior, but the summary address
> is configured by manually, and if one of the specific prefix within this
> summary range is down, the black hole(route to this specific prefix) will
> be formed.  PUA mechanism just want to amend this.
>
> Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such
> problem needs also be solved.
>
>
>
> If you are interested this topic, welcome to join us to the solution.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of *Gyan
> Mishra
>
>
> *Sent:* Thursday, August 6, 2020 4:44 PM
> *To:* Aijun Wang 
> *Cc:* Peter Psenak ; Robert Raszuk <
> rob...@raszuk.net>; Huzhibo ; Aijun Wang <
> wang...@chinatelecom.cn>; lsr ; Acee Lindem (acee) <
> a...@cisco.com>; Xiaoyaqun 
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun and authors
>
>
>
> I am catching up with this thread after reading through this draft.
>
>
>
> I understand the concept that we are trying to send a PUA advertisement
> which sounds similar to Rift Negative Disaggregation prefix now with a
>  null setting when a longer match component prefix that is part of a
> summary range is down to detect prefix down conditions with longer match
> component prefixes that are part of a summary.
>
>
>
> Basically how summarization works with both OSPF and ISIS is that at
> minimum a single longer match within the defined IA summary range must
> exist for the IA summary to be sent.  So the summary is sent conditionally
> similar to a BGP conditional advertisement or even a ospf default originate
> which requires a default in the RIB to exist before the advertisement is
> sent.  A good example of non conditional analogy with BGP if you have a
> null0 static for a summary for an exact match BGP advertisement the prefix
> is always advertised no matter what even if no component prefixes exist.
> This can result in black hole routing. BGP has conditional feature to
> conditionally advertisement based on existence of a route advertisement of
> downstream neighbor in the BGP RIB.  So with ospf and Isis the summary is
> in fact conditional similar to a BGP conditional advertisement and in the
> example given in the draft in section 3.1 when node T2 is down and pt2
> becomes unreachable and let’s say that prefix is 1.1.1.1/32 and the
> summary is 1.1.1.0/30 and no other component prefix exists within the
> summary range the prefix will not get adversed.  So there will not be any
> black hole.
>
>
>
> The summary represents all prefixes within the range that would be
> suppressed with the summary when advertised into the backbone area.
> However only at a minimum one prefix must exist in the range for the
> summary to be generated.  That is done by design as the summary represents
> all prefixes within the range.  So let’s say there are a 100 prefixes and
> let’s say a few devices are down and so now only 5 prefixes exist within
> the range.  By design it is OK for router to generate the summary for the 5
> prefixes it is representing and that will not cause any routing loop or
> black hole.
>
>
>
>
>
> I am trying to understand wage gap exists and what we are trying to solve
> related to summarization in the context of IPv6.  Both IPv4 and IPV6
> summarization operates the similarly as far as the requirement of at
> minimum a single component route within the summary range must exist  as a
> condition to be present in the RIB before the summary can be advertised.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Tue, Aug 4, 2020 at 11:25 PM Aijun Wang 
> wrote:
>
> Hi, Robert:
>
>
>
> *From:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *On Behalf Of 
> *Robert
> Raszuk
> *Sent:* Friday, July 31, 2020 6:21 PM
> *To:* Aijun Wang 
> *Cc:* Peter Psenak ; Huzhibo <
> huzh...@huawei.com>; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Xiaoyaqun <
> xiaoya...@huawei.com>
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> [WAJ] Such information is for underlay link state and should be flooded
> via IGP? The ambiguity arises from IGP summary behavior and should be
> solved by itself?
>
>
>
> Well if we look at this problem from a distance while on surface