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

[Les Ginsberg (ginsberg)]

Tony –

There are two options that have been proposed:

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.

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.
IN which case existing prefix SID advertisement is appropriate coupled with a 
means of identifying the address. There are two proposed encodings for that.

Pick either of the two options above and I would find it acceptable.

   Les

From: Tony Li 
Sent: Thursday, August 06, 2020 2:42 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


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

[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

[Gyan Mishra]

Hi Tony

See section 3.3.1 of RFC 8402 SR Architecture

https://tools.ietf.org/html/rfc8402#section-3.3.1

It has a nice graphical explanation of SR-MPLS Anycast usage.

The concept of Anycast SID is similar to Multicast group GDA conceptually
and similar to IGP routing anycast construct of proximity routing but more
like the former GDA based routing.

Basically you can have a group of nodes in the SR domain that can be
assigned an Anycast SID A and another group an Anycast SID B for the nodes
and a common group outer label Anycast SID is assigned to forward to the
Group of nodes represented by the Anycast SID.  The inner label is
basically a common label to forward to the group of nodes.

You can think of Anycast as similar to SR-TR prefix sid steering ECMP
pathing where all paths are active to get to the unicast destination.

In this case its all paths active but now to a pseudo multicast like
“anycast sid” group destination.

The concept of Anycast SID exists with SRv6 as well.

I think to your point I am not sure why it matters and can the Area prefix
be either unicast or Anycast.  As far at the area leader if that is a
single node then the node sid could be utilized and if the area leader is a
group or more then one node then a Anycast sid could be utilized.  I think
flexibility would be best so it can be either as you pointed out.

Kind Regards


Gyan

On Thu, Aug 6, 2020 at 12:32 PM Tony Li  wrote:

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



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Tony –

Not sure why this needs to be explained.
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.

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…

   Les


From: Tony Li 
Sent: Thursday, August 06, 2020 9:32 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02



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-flex-algo-08] Clarification on ASLA usage for flex-algo

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Thanks for the clarification and fast answer.

Indeed FAD does not encode any attributes. 
That was not the point I was trying to make.

.. 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]?
.. Similar for section 5.2 where a reference to RFC7471 and RFC3630 should be 
added together with explicit reference to [I-D.ietf-ospf-te-link-attr-reuse].

Explicit reference to ASLA encodings in section 5.1 and 5.2 will avoid 
confusion and avoid legacy link attribute encodings (rfc7810/5305/7471/3630) 
for flex-algo.

Could in section 11 be explicit reference to (e)ag, te-metric and delay link 
attributes MUST be encoded using ASLA..

G/


From: Peter Psenak 
Sent: Thursday, August 6, 2020 6:37:42 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
draft-ietf-lsr-flex-a...@ietf.org 
Cc: lsr@ietf.org 
Subject: Re: [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for 
flex-algo 
 
Hi Gunter,

On 06/08/2020 18:31, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Authors, All,
> 
> My understanding is that for new LSR applications we should select 
> either "ASLA encoding" or select "legacy encoding" for all Link attributes.
> 
> Not a mixture of both. There is a clear long term technology benefit of 
> using all ASLA encoding.
> 
> In draft-ietf-lsr-flex-algo-08 "Section 11: Advertisement of Link 
> Attributes for Flex-Algorithm" we find that use of ASLA is mandated
> 
> "
> 
>    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].
> 
> "
> 
> This is a 'normative' instruction that link attributes MUST use ASLA 
> encoding.
> 
> Hence link attributes like (e)ag, te-metric and delay MUST be ASLA encoded.
> 
> Is that correct understanding?

yes, for any link attributes used for flex-algo.

> 
> If yes, it is odd that some attributes are new ASLA and some other are 
> non-future proof 'LEGACY' encodings
> 
>   * Example#1: section 5.1 "ISIS Flexible Algorithm Definition Sub-TLV"
> and section 5.2 "OSPF Flexible Algorithm Definition TLV" point
> towards legacy encodings RFC7810 and RFC5305 (idnit RFC7810 is
> obsoleted by RFC8570).
>   * Example#2: section 5.2 "OSPF Flexible Algorithm Definition TLV" the
> normative references are missing

ASLA is link-attributes related (Application Specific Link Attributes).

ASLA can only be used to encode link attributes. FAD is not a link 
attribute, so it can not use ASLA.

thanks,
Peter

> 
> Sections 5.1 and 5.2 should update the link attribute encoding 
> references to reflect ASLA encoding as specified in section 11.
> 
> The text referencing legacy encodings should be removed
> 
> G/
> 

___
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

[Peter Psenak]

Hi Gunter,

On 06/08/2020 18:31, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:

Hi Authors, All,

My understanding is that for new LSR applications we should select 
either “ASLA encoding” or select “legacy encoding” for all Link attributes.


Not a mixture of both. There is a clear long term technology benefit of 
using all ASLA encoding.


In draft-ietf-lsr-flex-algo-08 “Section 11: Advertisement of Link 
Attributes for Flex-Algorithm” we find that use of ASLA is mandated


“

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

“

This is a ‘normative’ instruction that link attributes MUST use ASLA 
encoding.


Hence link attributes like (e)ag, te-metric and delay MUST be ASLA encoded.

Is that correct understanding?


yes, for any link attributes used for flex-algo.



If yes, it is odd that some attributes are new ASLA and some other are 
non-future proof ‘LEGACY’ encodings


  * Example#1: section 5.1 “ISIS Flexible Algorithm Definition Sub-TLV”
and section 5.2 “OSPF Flexible Algorithm Definition TLV” point
towards legacy encodings RFC7810 and RFC5305 (idnit RFC7810 is
obsoleted by RFC8570).
  * Example#2: section 5.2 “OSPF Flexible Algorithm Definition TLV” the
normative references are missing


ASLA is link-attributes related (Application Specific Link Attributes).

ASLA can only be used to encode link attributes. FAD is not a link 
attribute, so it can not use ASLA.


thanks,
Peter



Sections 5.1 and 5.2 should update the link attribute encoding 
references to reflect ASLA encoding as specified in section 11.


The text referencing legacy encodings should be removed

G/



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

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

[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

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

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Hi Authors, All,

My understanding is that for new LSR applications we should select either "ASLA 
encoding" or select "legacy encoding" for all Link attributes.
Not a mixture of both. There is a clear long term technology benefit of using 
all ASLA encoding.

In draft-ietf-lsr-flex-algo-08 "Section 11: Advertisement of Link Attributes 
for Flex-Algorithm" we find that use of ASLA is mandated

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

This is a 'normative' instruction that link attributes MUST use ASLA encoding.
Hence link attributes like (e)ag, te-metric and delay MUST be ASLA encoded.

Is that correct understanding?

If yes, it is odd that some attributes are new ASLA and some other are 
non-future proof 'LEGACY' encodings

  *   Example#1: section 5.1 "ISIS Flexible Algorithm Definition Sub-TLV" and 
section 5.2 "OSPF Flexible Algorithm Definition TLV" point towards legacy 
encodings RFC7810 and RFC5305 (idnit RFC7810 is obsoleted by RFC8570).
  *   Example#2: section 5.2 "OSPF Flexible Algorithm Definition TLV" the 
normative references are missing


Sections 5.1 and 5.2 should update the link attribute encoding references to 
reflect ASLA encoding as specified in section 11.
The text referencing legacy encodings should be removed

G/

___
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 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 it seems
> like an IGP issue (not to mention some which use BGP as IGP :) IMO it is
> only hurting when you have some service overlay on top utilizing the IGP.
>
> *[WAJ] There are situations that the PUA mechanism apply when no service
> overlay running over IGP.  Scenarios described in
> draft-wang-lsr-prefix-unreachable-annoucement-03#section-3
> 
> are not tightly coupled with the overlay service.*
>
>
>
> So typically today if I am running any service with BGP I do count on BGP
> to remove routes which are no longer reachable. IGP just tells me how to
> get to the next hop, which direction to go and not if the endpoint (service
> CPE or PE connected to given CE) is up or down.
>
>
>
> So today smart BGP implementations in good network design can use RD based
> withdraws to very fast (milliseconds) remove the affected service routes.
> When I said should we do it in BGP I meant to ask WG if this is good enough
> to quickly remove service routes. If not maybe we should send such affected
> next hop in BGP to even faster invalidate all routes with such next hop as
> failing PE.
>
>
>
> Bottom line if you think the problem is IGP then I think Acee's comments
> apply.
>
> *[WAJ] Which comment is not addressed yet?*
>
>
>
> Last - See today you are bringing the case to signal transition to DOWN
> ... but for some people and applications it may be not enough. In fact
> UP/DOWN they can get via BGP. But if you have two ABRs and one will due to
> topology changes in its area suddenly will be forced to reach atomic
> destination covered by summary over much higher metric path that for