Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

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

Inline: GV>

From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 5:26 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Hi Gunter,

I am having troubles understanding the value of ‘The Multi-part TLV Capability’ 
flag.
What would break if ‘Multi-part TLV Capability’ flag would not exist? 


A system that supported MP-TLVs would not be able to determine that there were 
other systems in the area that did not support MP-TLVs.  The system might then 
advertise MP-TLVs and they would be misinterpreted or cause system crashes in 
the systems that did not support them.

GV> crashes? I really hope that is not happening.
GV> When a legacy router receives MP-TLVs from another system and legacy router 
has no support for handling MP-TLV, then yes, things get misinterpreted. There 
is nothing wrong with that, is there? Do you have an example where things go 
wrong? 

If we want to introduce MP-TLVs, that change would warrant the existence of the 
flag.  

GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS behave 
better

I dispute that a binary flag warrants the word ‘complexity’.

GV>  living without binary flag is simpler and less complex then dealing with a 
binary flag. (i.e. what, when, how, why, who sets this flag?)

Note: thoughts about the flag: What if a system by accident sends flip-flopping 
(set/unset/set/unset/etc) of this flag? 

Then other systems might misinterpret the results and generate inconsistent 
TLVs.  That would be bad.

GV> correct, no good at all.

What if an advertising system support multi-tlv for TLV ‘A’ but not for TLV ‘B’?

We are not allowing that level of granularity.  A system that is going to 
support MP-TLVs should take care to operate correctly for ALL TLVs before 
advertising that it supports them.

GV> I suspect that 'ALL TLVs' is a reference to  ALL TLVs supported by the 
local system. This means that e.g. when new TLVs would be supported after a 
system upgrade, that the operator has to be aware and correct the flag during 
each single upgrade. 

GV> Unfortunately I remain to have troubles understanding the value "Multi-part 
TLV Capability’ flag brings to an ISIS network. 
  * Without flag it is indeed uncertain if area wide mp-tlv is supported 
(sub-optimal). 
  * but with catch all MP-TLV flag I am not sure we improve ISIS operation: 
  ** Who guarantees that the flag is set correctly on all systems at all times
  ** Maybe all systems falls back to advertise single TLV because another 
(legacy?) system advertise a wrong flag  (sub-optimal)
  ** Legacy system with MP-TLV support gets upgraded and now supports 
additional TLVs but not with MP-TLV...  ?manual intervention? (sub-optimal)
  ** what, when, how, why, who sets the MP-TLV flag? What with flapping of 
MP-TLV flag (undefined)

G/

Tony



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

Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

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

draft-pkaneria-lsr-multi-tlv-01 is a fine informational read and described the 
playing field of multi-part tlv’s well.

I am having troubles understanding the value of ‘The Multi-part TLV Capability’ 
flag.
What would break if ‘Multi-part TLV Capability’ flag would not exist?
IS-IS has been working well for many years. Why would that suddenly change and 
mandate existence and complexity of a ‘Multi-part TLV Capability’ flag?
G/

Note: thoughts about the flag: What if a system by accident sends flip-flopping 
(set/unset/set/unset/etc) of this flag? What if an advertising system support 
multi-tlv for TLV ‘A’ but not for TLV ‘B’?


From: Lsr  On Behalf Of Tony Li
Sent: Tuesday, July 5, 2022 3:09 AM
To: lsr 
Subject: [Lsr] Fwd: New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Hi all,

This is an update to reflect some of the discussions to date. A diff is 
attached.  Most of this is a change to terminology to stop using the word 
‘instance’ and shift to using ‘multi-part TLV’.

We have been having a discussion about adding more discussion of keys in this 
document.  We have not done that yet.  This is not an indication of refusal, 
just making one baby step forward.  More to come… Text contributions are more 
than welcome.

Other comments?

Regards,
Tony






Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt
Date: July 4, 2022 at 6:04:37 PM PDT
To: "Antoni Przygienda" mailto:p...@juniper.net>>, "Chris 
Bowers" mailto:cbo...@juniper.net>>, "Les Ginsberg" 
mailto:ginsb...@cisco.com>>, "Parag Kaneriya" 
mailto:pkane...@juniper.net>>, "Shraddha Hegde" 
mailto:shrad...@juniper.net>>, "Tony Li" 
mailto:tony...@tony.li>>, "Tony Przygienda" 
mailto:p...@juniper.net>>


A new version of I-D, draft-pkaneria-lsr-multi-tlv-01.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name: draft-pkaneria-lsr-multi-tlv
Revision: 01
Title: Multi-part TLVs in IS-IS
Document date: 2022-07-04
Group: Individual Submission
Pages: 7
URL:
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.txt
Status: https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-pkaneria-lsr-multi-tlv-01

Abstract:
  New technologies are adding new information into IS-IS while
  deployment scales are simultaneously increasing, causing the contents
  of many critical TLVs to exceed the currently supported limit of 255
  octets.  Extensions such as [RFC7356] require significant IS-IS
  changes that could help address the problem, but a less drastic
  solution would be beneficial.  This document codifies the common
  mechanism of extending the TLV content space through multiple TLVs.




The IETF Secretariat


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

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

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

wrt partitioned area’s and UPA’s. The wang PUA draft has an interesting 
proposal for assuring that even with UPAs and partitioned area’s 
non-conflicting information exist.
The solution proposal does come at cost of increased ISIS churn. This could be 
an acceptable cost, especially considering that UPAs will only appear by 
exception and even more rare in combination with area partitioning.

Lets consider the following (based upon section “3.2 from 
draft-wang-lsr-prefix-unreachable”):

For ISIS,  R2 L1/L2 would advertise the PUA for Pt2.
R4 L1/L2 router receives the L2 PUA route for Pt2 and because it is also 
summarizing Pt2 from L1, it now decides to advertise a specific route to Pt2.
R2 now sees that R4 advertises a specific route for Pt2 and programs Pt2 next 
hop to R4. This will stop the PUA advertisement on R2 immediately.

Although this enhancement as described is in the 
draft-wang-lsr-prefix-unreachable draft it should work with 
draft-ppsenak-lsr-igp-ureach-prefix. A side effect is more churn.
This setup where R2 and R4 only see each other in L2 causes a lot of churn as a 
PUA needs to be advertised for Pt2 and all downstream routes of T2.
On top , R4 now advertises specific route for each of the PUA’s and a bit later 
R2 floods the same LSPs again but without the PUA’s.


***
 +-+--++-+--+
 | +--++--+   ++-+   ++-++-++   + -++--+|
 | |S1++S2+---+R1+---|R0++R2+---+T1++T2||
 | +-++Ps1 +-++   ++-+   +--++-++   Pt2 +-++|
 |   |   | |   | ||   | |
 |   |   | |   | ||   | |
 |   |   | |  L2 ||   | |
 |   |   | |   | ||   | |
 | +-++Ps4 +-++   ++-+   +-++    Pt4+-++|
 | |S4++S3+---+R3+---+R4+---+T3++T4||
 | +--++--+   ++-+   +-++   ++-++--+|
 | |   ||
 | |   ||
 | | ISIS L2   |  ISIS L1   |
 +-+---++

Inter-Area Prefix Unreachable Announcement Scenario


3.2.  Inter-Area Links Failure Scenario

   In a link failure scenario, if the link between T1/T2 and T1/T3 are
   down, R2 will not be able to reach node T2.  But as R2 and R4 do the
   summary announcement, and the summary address covers the bgp next hop
   prefix of Pt2, other nodes in area 0 area 1 will still send traffic
   to T2 bgp next hop prefix Pt2 via the border router R2, thus black
   hole sink routing the traffic.

   In such a situation, the border router R2 should notify other routers
   that it can't reach the prefix Pt2, and lets the other ABRs(R4) that
   can reach prefix Pt2 advertise one specific route to Pt2, then the
   internal routers will select R4 as the bypass router to reach prefix
   Pt2.
***

G/


-Original Message-
From: Peter Psenak 
Sent: Thursday, June 16, 2022 12:04 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Gyan Mishra ; Voyer, Daniel 

Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 
; lsr@ietf.org
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Hi Gunter,

please see inline (##PP):

On 16/06/2022 10:09, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Gyan, Daniel, Peter, All,
>
> Thanks for sharing your insights and I agree mostly with your feedback
>
> I agree and understand that summarization is needed to reduce the size
> of the LSDB. I also agree summarization good design practice,
> especially with IPv6 and SRv6 in mind. There never has been doubt about that.
>
> I am not sure I agree that UAP/UPA is ‘optimal-design’. Maybe it is
> the best we can do, however I have a healthy worry we could be
> suffering tunnel vision and that proposed solution may not be good enough.
>
> We should not be blind and believe that advertising UPA/PUA does not
> come without a cost. The architectural PUA/UPA usage complexity cost
> may not be worth the effort (none of the integration of using a
> PUA/UPA event triggers come for free). Do we really believe that
> PUA/UPA solve all the SID reachability problems for all IGP network
> design and SR use-cases elegantly? Maybe some use-case design
> constraints and assumptions should be documented to clarify
> architecturally where PUA/UPA is most beneficial for operators? Just
> stating “outside scope of the draft” seems unfair to operators
> interested in PUA/UPAs

##PP
we are trying to solve a particular problem of remote PE going down in network 
where summarization is used. I believe that is stated clearly in the UPA draft.

>
> Let me give tw

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

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

Hi Robert, Peter, Bruno

You wrote:
“Aas there is no association between node_id (perhaps loopback) and SIDs (note 
that egress can use many SIDs) UPA really does not signal anything about SIDs 
reachability or liveness. “

Sure, but UPA signals that a locator is unreachable, would that not result for 
the SRv6 SID to become unreachable as well?

I understood that UPA have increased value add benefit when using with SRv6. If 
suddenly a locator becomes unreachable, then it I guess the associated 128 bit 
SIDs become unreachable too, causing an event for something to happen in the 
transport network to fix the problem.

That being said, Peter makes a good point stating that UPA is not solving the 
problem of partitioning areas, and hence, maybe my use-case is not overly 
relevant.

So progressing, an operator using ABR based summarization then there are few 
options:

  1.  No summarization at all at ABRs
  2.  Summarize on ABR all prefixes that can be summarized
  3.  Summarize all prefixes that are not associated with PEs and remain 
advertising individual PE addresses
  4.  Summarize all prefixes and use UPA’s to advertise unreachability of 
protected prefixes

We all know that option 1 -3 work well and has been working well for long time. 
Behavior is very well understood

With the new option 4, to add value, applications need to get what is being 
referenced as ‘vendor secret sauce’ … I can already see the fun caused by 
inconsistent behavior and interop issues due to under specification.

The question I remain to have is if the UPA provide higher benefit as the tax 
it introduces. I can see operators suffer due to under specification, causing 
interop and inconsistent behaviors.


I agree with Bruno’s statement “If you believe that all you need is 
RFC5305/RFC5308 I guess this means that we don't need 
draft-ppsenak-lsr-igp-ureach-prefix-announce”

G/


From: Robert Raszuk 
Sent: Thursday, June 16, 2022 11:54 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: Gyan Mishra ; Voyer, Daniel 
; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 
; lsr@ietf.org
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Gunter,

(1) Multiple-ABRs

I was wondering for example if a ingress router receives a PUA signaling that a 
given locator becomes unreachable, does that actually really signals that the 
SID ‘really’ is unreachable for a router?

Aas there is no association between node_id (perhaps loopback) and SIDs (note 
that egress can use many SIDs) UPA really does not signal anything about SIDs 
reachability or liveness.

 For example (simple design to illustrate the corner-case):

ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2
 |  |
 |  |
 +area#1---ABR#3---area---ABR#4---area#3+

What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not?
In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate a 
PUA/UPA.
How is ingressPE#1 supposed to handle this situation? The only thing 
ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may not 
have changed at all and remains perfectly reacheable.

Valid case. But PE1 should only switch when alternative backup path exists. If 
there is a single path it should do nothing in any case of receiving UPA. We 
have discussed that case before and as you know the formal answer was "out of 
scope" or "vendor's secret sauce" :).

The justification here is that switching to healthy backup is better then 
continue using perhaps semi-sick path.

Best,
R.

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

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

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

Hi Gyan, Daniel, Peter, All,

Thanks for sharing your insights and I agree mostly with your feedback

I agree and understand that summarization is needed to reduce the size of the 
LSDB. I also agree summarization good design practice, especially with IPv6 and 
SRv6 in mind. There never has been doubt about that.
I am not sure I agree that UAP/UPA is ‘optimal-design’. Maybe it is the best we 
can do, however I have a healthy worry we could be suffering tunnel vision and 
that proposed solution may not be good enough.
We should not be blind and believe that advertising UPA/PUA does not come 
without a cost. The architectural PUA/UPA usage complexity cost may not be 
worth the effort (none of the integration of using a PUA/UPA event triggers 
come for free). Do we really believe that PUA/UPA solve all the SID 
reachability problems for all IGP network design and SR use-cases elegantly? 
Maybe some use-case design constraints and assumptions should be documented to 
clarify architecturally where PUA/UPA is most beneficial for operators? Just 
stating “outside scope of the draft” seems unfair to operators interested in 
PUA/UPAs

Let me give two examples where PUA/UPA benefit is unclear:

(1) Multiple-ABRs

I was wondering for example if a ingress router receives a PUA signaling that a 
given locator becomes unreachable, does that actually really signals that the 
SID ‘really’ is unreachable for a router?

For example (simple design to illustrate the corner-case):

ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2
 |  |
 |  |
 +area#1---ABR#3---area---ABR#4---area#3+

What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not?
In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate a 
PUA/UPA.
How is ingressPE#1 supposed to handle this situation? The only thing 
ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may not 
have changed at all and remains perfectly reacheable.


(2) with sr-policy or SRv6 SRTE
What if we have an inter-area/domain/level SRTE or sr-policy and suddenly there 
is a PUA/UPA for one of the SIDs in the sid-list of the path.
will this impact the srte or sr-policy in any way? Will transit routers do 
anything with the UPA/PUA and drop packets. Will transit routers trigger 
fast-restoration?
Can PCEs/controllers use the SID for crafting paths? Will all SRTE/sr-policy 
using the locator be pruned or re-signaled?
Will ingress router do something with the PUA information? Should PUA/UPA draft 
give guidelines around this?

Be well,
G/







If there is an SRTE or sr-policy using a given SID somewhere in the SID list… 
and suddenly



From: Gyan Mishra 
Sent: Thursday, June 16, 2022 6:12 AM
To: Voyer, Daniel 
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 
; lsr@ietf.org
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?


Summarization has always been a best practice for network scalability thereby 
reducing the size of the RIB and LSDB.

So in this case as Dan pointed out,  the summary route is an abstraction of the 
area and so if a component prefix of the summary became unreachable we need a 
way to signal that the PE next hop is no longer reachable to help optimize 
convergence.

We are just trying to make summarization work better then it does today so we 
don’t have to rely on domain wide flooding of host routes.

Thanks

Gyan


On Wed, Jun 15, 2022 at 4:42 PM Voyer, Daniel 
mailto:40bell...@dmarc.ietf.org>> wrote:
Hi Gunter,

Thanks for your comments,

The idea, here, with summarization is to "reduce" the LSDB quite a lots and 
make a given backbone much more scalable / flexible and allow to simplify NNI's 
within that given backbones considerably.
Summarization is "needed" for better scale and, in the context of IPv6, will 
help in preventing blowing up the IGP.  With the size of an IPv6 prefix range 
(ex. /64) allocated per domain - summarization will help to contain the LSDB to 
that domain.

What we are "highlighting" in draft-ppsenak-lsr-igp-ureach-prefix-announce-00, 
is an easy way to overcome the fact that PEs are hidden behind a summary route 
and need a fast way to notify other PEs when they become unreachable.

I don't see "over-engineering" here, I see "optimal-engineering" instead.

Thanks
Dan

On 2022-06-14, 4:59 AM, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
mailto:gunter.van_de_ve...@nokia.com>> wrote:

Hi All,

When reading both proposals about PUA's:
* draft-ppsenak-lsr-igp-ureach-prefix-announce-00
* draft-wang-lsr-prefix-unreachable-annoucement-09

The identified problem space seems a correct observation, and indeed 
summaries hide remote area networ

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

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

Hi Robert,

I agree with you that the operator problem space is not limited to 
multi-area/levels with IGP summarisation.

With the PUA/UPA proposals I get the feeling that LSR WG is jumping into the 
deep-end and is re-vectoring the IGP to carry opaque information not used for 
SPF/cSPF.
I believe we should be conservative for such and if LSR WG progresses with such 
decision.

It could very well be that re-vectoring is the best solution, but I guess we 
need to agree first on understanding the operator problem space.

G/

From: Robert Raszuk 
Sent: Tuesday, June 14, 2022 11:51 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 

Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Hello Gunter,

I agree with pretty much all you said except the conclusion - do nothing :).

To me if you need to accelerate connectivity restoration upon an unlikely event 
like a complete PE failure the right vehicle to signal this is within the 
service layer itself. Let's keep in mind that links do fail a lot in the 
networks - routers do not (or they do it is multiple orders of magnitude less 
frequent event). Especially links on the PE-CE boundaries do fail a lot.

Removal of next hop reachability can be done with BGP and based on BGP native 
recursion will have the exact same effect as presented ideas. Moreover it will 
be stateful for the endpoints which again to me is a feature not a bug.

Some suggested to define a new extension in BGP to signal it even without using 
double recursion - well one of them has been proposed in the past - 
https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt At that time 
the feedback received was that native BGP withdraws are fast enough so no need 
to bother. Well those native withdrawals are working today as well as some 
claim that specific implementations can withdraw RD:* when PE hosting such RDs 
fail and RDs are allocated in a unique per VRF fashion.

Then we have the DROID proposal which again may look like overkill for this 
very problem, but if you consider the bigger picture of what networks control 
plane pub-sub signalling needs, it establishes the foundation for such.

Many thanks,
Robert


On Tue, Jun 14, 2022 at 10:59 AM Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>> wrote:
Hi All,

When reading both proposals about PUA's:
* draft-ppsenak-lsr-igp-ureach-prefix-announce-00
* draft-wang-lsr-prefix-unreachable-annoucement-09

The identified problem space seems a correct observation, and indeed summaries 
hide remote area network instabilities. It is one of the perceived benefits of 
using summaries. The place in the network where this hiding takes the most 
impact upon convergence is at service nodes (PE's for L3/L2/transport) where 
due to the summarization its difficult to detect that the transport tunnel 
end-point suddenly becomes unreachable. My concern however is if it really is a 
problem that is worthy for LSR WG to solve.

To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is not a 
preferred solution due to the expectation that all nodes in an area must be 
upgraded to support the IGP capability. From this operational perspective the 
draft "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is more elegant, as 
only the A(S)BR's and particular PEs must be upgraded to support PUA's. I do 
have concerns about the number of PUA advertisements in hierarchically 
summarized networks (/24 (site) -> /20 (region) -> /16 (core)). More specific, 
in the /16 backbone area, how many of these PUAs will be floating around 
creating LSP LSDB update churns? How to control the potentially exponential 
number of observed PUAs from floating everywhere? (will this lead to OSPF type 
NSSA areas where areas will be purged from these PUAs for scaling stability?)

Long story short, should we not take a step back and re-think this identified 
problem space? Is the proposed solution space not more evil as the problem 
space? We do summarization because it brings stability and reduce the number of 
link state updates within an area. And now with PUA we re-introduce additional 
link state updates (PUAs), we blow up the LSDB with information opaque to SPF 
best-path calculation. In addition there is suggestion of new state-machinery 
to track the igp reachability of 'protected' prefixes and there is maybe desire 
to contain or filter updates cross inter-area boundaries. And finally, how will 
we represent and track PUA in the RTM?

What is wrong with simply not doing summaries and forget about these PUAs to 
pinch holes in the summary prefixes? this worked very well during last two 
decennia. Are we not over-engineering with PUAs?

G/

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
htt

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

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

Hi Aijun,

Thanks for sharing your thoughts.
I agree that the observed problem is valid and is service impacting for 
operators.

It is wise to be conservative about using the IGP as an API to advertise opaque 
properties. The PUA/UPA have nothing to do with calculating SPF/cSPF.

Maybe we should first try to understand and agree on the full problem space 
before we directly jump into IGP encodings and risk over-engineering a solution?

G/




From: Aijun Wang 
Sent: Tuesday, June 14, 2022 12:27 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 

Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Hi, Gunter:

Let me try to answer some of your concerns.

The reason that we prefer to the Summary+PUA/UPA solution is that the node 
failure(which is the main scenario that we focus now) is one rarely thing in 
the network. Then the unreachable event triggered mechanism is more efficient 
than advertising all of the node’s reachable address. This point has been 
discussed in the mail list in past.

In the 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-8,
 we have illustrated how to control the advertisement of PUA message on the 
ABR. If this can’t settle your concerns, we can consider more policy on the ABR.

Regarding to the tracking and representation of PUA in RTM, we have proposed in 
the earlier version of this draft, that is to install one black hole route to 
the specified detailed prefix.

The reason that PUA requires routers within one area to be upgraded is that it 
want to avoid the situations when the router doesn’t recognize PUA message and 
misbehave. We are considering the convergence of PUA/UPA solutions, which may 
relax such requirements during deployment.


Aijun Wang
China Telecom


On Jun 14, 2022, at 16:59, Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>> wrote:
Hi All,

When reading both proposals about PUA's:
* draft-ppsenak-lsr-igp-ureach-prefix-announce-00
* draft-wang-lsr-prefix-unreachable-annoucement-09

The identified problem space seems a correct observation, and indeed summaries 
hide remote area network instabilities. It is one of the perceived benefits of 
using summaries. The place in the network where this hiding takes the most 
impact upon convergence is at service nodes (PE's for L3/L2/transport) where 
due to the summarization its difficult to detect that the transport tunnel 
end-point suddenly becomes unreachable. My concern however is if it really is a 
problem that is worthy for LSR WG to solve.

To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is not a 
preferred solution due to the expectation that all nodes in an area must be 
upgraded to support the IGP capability. From this operational perspective the 
draft "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is more elegant, as 
only the A(S)BR's and particular PEs must be upgraded to support PUA's. I do 
have concerns about the number of PUA advertisements in hierarchically 
summarized networks (/24 (site) -> /20 (region) -> /16 (core)). More specific, 
in the /16 backbone area, how many of these PUAs will be floating around 
creating LSP LSDB update churns? How to control the potentially exponential 
number of observed PUAs from floating everywhere? (will this lead to OSPF type 
NSSA areas where areas will be purged from these PUAs for scaling stability?)

Long story short, should we not take a step back and re-think this identified 
problem space? Is the proposed solution space not more evil as the problem 
space? We do summarization because it brings stability and reduce the number of 
link state updates within an area. And now with PUA we re-introduce additional 
link state updates (PUAs), we blow up the LSDB with information opaque to SPF 
best-path calculation. In addition there is suggestion of new state-machinery 
to track the igp reachability of 'protected' prefixes and there is maybe desire 
to contain or filter updates cross inter-area boundaries. And finally, how will 
we represent and track PUA in the RTM?

What is wrong with simply not doing summaries and forget about these PUAs to 
pinch holes in the summary prefixes? this worked very well during last two 
decennia. Are we not over-engineering with PUAs?

G/

___
Lsr mailing list
Lsr@ietf.org<mailto: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] Thoughts about PUAs - are we not over-engineering?

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

Hi Peter, All,

From a BGP perspective (PE service nodes) the event detection when transport 
tunnel end-point suddenly becomes unreachable is an operational problem. I 
think we all agree.
This problem exists in any multi-domain network, and is not limited to a 
multi-area/level IGP with summarization. Hence my doubts that simple encodings 
using the IGP as API for unreachability signaling is an optimal solution.  

Churning the LSDB for these things doesn't seem right.  Would this mean that we 
hack the IGP implementation so we don't trigger SPFs on rx of these updates?  
Another concern is how we hook into BGP sideways to update it. Typically a 
router just looks at RTM and tunnel-tables for reachability. Now it would have 
check all the time a separate bypass-list.  
What about the pseudo-state. On startup I would imagine we would have to 
originate this PUA until a certain point?

Some consideration about installing the PUA route as a blackhole route, it does 
not seem an option because resolution of BGP next-hops with blackhole /32 
routes has to continue to mean “drop” matching traffic because of the 
widespread way this is used for DDOS protection. So there is need another 
“install” type for the “unreachable” IGP prefix which does not exist yet.

To make IGP based Prefix-unreachability-signal successful seems not a trivial 
task pe-to-pe, and involves more than simplistic dumping of opaque link-state 
messages into IGP and to re-vector interior routing as an API. I'm a bit 
tormented regarding the potential evil caused to IGP for signaling 
prefix-unreachability. It may not be worth the effort. Especially when 
realizing that the problem space is not limited to multi-area/level 
summarization but instead exists in any multi-domain network. 

Maybe IETF should consider looking at the bigger picture, at service level, and 
document a full service level solution framework instead of looking only at IGP 
in atomic fashion.

G/

-Original Message-
From: Peter Psenak  
Sent: Tuesday, June 14, 2022 5:46 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
lsr 
Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 

Subject: Re: Thoughts about PUAs - are we not over-engineering?

Hi Gunter,

please see inline:

On 14/06/2022 10:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi All,
> 
> When reading both proposals about PUA's:
> * draft-ppsenak-lsr-igp-ureach-prefix-announce-00
> * draft-wang-lsr-prefix-unreachable-annoucement-09
> 
> The identified problem space seems a correct observation, and indeed 
> summaries hide remote area network instabilities. It is one of the perceived 
> benefits of using summaries. The place in the network where this hiding takes 
> the most impact upon convergence is at service nodes (PE's for 
> L3/L2/transport) where due to the summarization its difficult to detect that 
> the transport tunnel end-point suddenly becomes unreachable. My concern 
> however is if it really is a problem that is worthy for LSR WG to solve.

the request to address the problem is coming from the field. The scale of the 
networks in the field is growing significantly and the summarization is being 
implemented to keep the prefix scale under control.


> 
> To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is 
> not a preferred solution due to the expectation that all nodes in an 
> area must be upgraded to support the IGP capability. From this 
> operational perspective the draft 
> "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is more elegant, as 
> only the A(S)BR's and particular PEs must be upgraded to support 
> PUA's. I do have concerns about the number of PUA advertisements in 
> hierarchically summarized networks (/24 (site) -> /20 (region) -> /16 
> (core)). More specific, in the /16 backbone area, how many of these 
> PUAs will be floating around creating LSP LSDB update churns? How to 
> control the potentially exponential number of observed PUAs from 
> floating everywhere? (will this lead to OSPF type NSSA areas where 
> areas will be purged from these PUAs for scaling stability?)

Node going down is a rare event. The expected number of UPAs at any given time 
is very small. Implementations can limit the number of UPAs on ABR/ASBR in case 
of a catastrophic events, in which case the UPAs would hardly help anyway.

> 
> Long story short, should we not take a step back and re-think this identified 
> problem space? Is the proposed solution space not more evil as the problem 
> space? We do summarization because it brings stability and reduce the number 
> of link state updates within an area. And now with PUA we re-introduce 
> additional link state updates (PUAs), we blow up the LSDB with information 
> opaque to SPF best-path calculation. In addition there is su

[Lsr] Thoughts about PUAs - are we not over-engineering?

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

Hi All,

When reading both proposals about PUA's:
* draft-ppsenak-lsr-igp-ureach-prefix-announce-00
* draft-wang-lsr-prefix-unreachable-annoucement-09

The identified problem space seems a correct observation, and indeed summaries 
hide remote area network instabilities. It is one of the perceived benefits of 
using summaries. The place in the network where this hiding takes the most 
impact upon convergence is at service nodes (PE's for L3/L2/transport) where 
due to the summarization its difficult to detect that the transport tunnel 
end-point suddenly becomes unreachable. My concern however is if it really is a 
problem that is worthy for LSR WG to solve.

To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is not a 
preferred solution due to the expectation that all nodes in an area must be 
upgraded to support the IGP capability. From this operational perspective the 
draft "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is more elegant, as 
only the A(S)BR's and particular PEs must be upgraded to support PUA's. I do 
have concerns about the number of PUA advertisements in hierarchically 
summarized networks (/24 (site) -> /20 (region) -> /16 (core)). More specific, 
in the /16 backbone area, how many of these PUAs will be floating around 
creating LSP LSDB update churns? How to control the potentially exponential 
number of observed PUAs from floating everywhere? (will this lead to OSPF type 
NSSA areas where areas will be purged from these PUAs for scaling stability?)

Long story short, should we not take a step back and re-think this identified 
problem space? Is the proposed solution space not more evil as the problem 
space? We do summarization because it brings stability and reduce the number of 
link state updates within an area. And now with PUA we re-introduce additional 
link state updates (PUAs), we blow up the LSDB with information opaque to SPF 
best-path calculation. In addition there is suggestion of new state-machinery 
to track the igp reachability of 'protected' prefixes and there is maybe desire 
to contain or filter updates cross inter-area boundaries. And finally, how will 
we represent and track PUA in the RTM?

What is wrong with simply not doing summaries and forget about these PUAs to 
pinch holes in the summary prefixes? this worked very well during last two 
decennia. Are we not over-engineering with PUAs?

G/

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

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

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

Hi Gyan,

I was talking about the use-case where we create two flex-algo’s and the desire 
is that they for example avoid congruent optical paths to avoid that a single 
fiber cut, would impact both streams. For some high value live-live streams or 
financials this may be an important service property. This type of flex-algo 
capability was a use-case about 1.5 a 2 years ago and caused the flex-algo to 
add exclude-srlg into the FAD to support such use-case.

The use-case was not about FRR, or RSVP-TE or anything similar. Advertising 
link properties is taken care of by the legacy and ASLA TE IGP attributes.  The 
requested ‘avoid congruent optical paths’ use-case added the exclude-srlg 
subTLV within the flex-algo FAD, but unlike the EAG, the SRLG can theoretically 
cause overflow of 255 octet subTLV under certain (mostly theoretical) 
circumstance.

I am in full agreement with Peter, that excluding 100s of SRLG is a something 
we will unlikely encounter, but then again, I see sometimes mythical oddness in 
use-case requests and I can not predict what requests future will bring. I am 
not asking for bigger or multiple SRLG subTLVs, but hope to find guidance to 
have implementation X behave identical/similar as implementation Y when such 
condition occurs.

G/

From: Gyan Mishra 
Sent: Thursday, March 10, 2022 5:05 AM
To: Tony Li 
Cc: Peter Psenak ; Van De Velde, Gunter (Nokia - BE/Antwerp) 
; lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-00.txt


Gunter

The use case for SRLG is only related to RSVP-TE FRR protection is my 
understanding.

However, Flex Algo is only applicable to SR forwarding plane SR-MPLS and SRv6?

Correct?

RSVP-TE FRR SRLG protection application can be used in parallel to SR-MPLS or 
SRv6 but in that case they would be 3 different ASLA apps if used on the same 
link.

For SR-MPLS, SR forwarding plane you could use RSVP-TE SRLG protection or SR-TE 
protection schemes.

I don’t think the RSVP-TE FRR SRLG protection would apply to SR-TE protection 
to use the concept of SRLG  with SR-MPLS with Flex Algo or would it apply.


Kind Regards

Gyan



On Fri, Mar 4, 2022 at 1:03 PM Tony Li 
mailto:tony...@tony.li>> wrote:

Peter,

the combination is the (a) problem and that will be fixed. We are talking 
problem (b) only now.


Ah, my apologies, I was unclear on the applicability of your statements.



I'm not trying under-specify how to deal with overflow - we need to specify it, 
no disagreement there.


I look forward to seeing a proposal. I propose allowing multiple FAD and 
concatenation of the contents.



What I'm trying to see of we need to support the "merge" at FAD sub-TLV level.


I’ll agree that that’s lower priority.  I think we should, as a matter of 
completeness.

Tony

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

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

My point to Tony was that there may be subTLVs out there that normative 
prescribe a restriction that only a single occurrence may exist. For flex-algo 
that is exactly one FAD for each algorithm.

Coming back to flex-algo FAD. It is indeed easy to mix things up sometimes, 
however this time maybe I am not?

I believe that your assumption is that the FAD for a single algorithm can never 
grow bigger as a 256 octets.
While that is a realistic and pragmatic assumption, it may not necessary be 
100% correct in all use-cases.

What if the FAD use SRLGs? Each of these SRLGs are big (4 octets) in size and 
will consume significant subTLV space resources and many of those may overrun 
the size of the FAD. So if we have a theoretical network with a theoretical 
use-case that wants to exclude, lets say 64, SRLGs, then how would that fit 
into a single FAD for a single algorithm?

Anyway, my point was that draft-pkaneria-lsr-multi-tlv may benefit to call-out 
subTLVs that by normative reference can only exist one time, in one place, like 
for example the flex-algo FAD.

G/

-Original Message-
From: Peter Psenak  
Sent: Wednesday, March 2, 2022 8:40 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Tony Li ; lsr 
Subject: Re: [Lsr] Fwd: New Version Notification for 
draft-pkaneria-lsr-multi-tlv-00.txt

Gunter,

I'm afraid you are mixing two different things.

Flex-algo draft limits the FAD advertisement for a SINGLE algo to one on any 
originator.

It DOES NOT limit in any way how many FADs for DIFFERENT algos any originator 
can send.

There are implementations that already support more FADs than can fit in a 
single TLV-242, in which case FADs are sent in multiple of them.

thanks,
Peter


On 02/03/2022 07:23, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Tony,
> 
> Interesting write-up. The proposal seems more operation friendly at 
> first sight as the alternate solutions.
> 
> A while ago I was bumping into limitation of advertising a flex-algo 
> FAD, and realized that only one is allowed and more seem to be 
> forbidden by the draft
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo#section
> -5.1 
> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo#sectio
> n-5.1>
> 
>     The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number, 
> but
> 
>     a router MUST NOT advertise more than one IS-IS FAD Sub-TLV for a
> 
>     given Flexible-Algorithm.  A router receiving multiple IS-IS FAD 
> Sub-
> 
>     TLVs for a given Flexible-Algorithm from the same originator MUST
> 
>     select the first advertisement in the lowest numbered LSP.
> 
> Is draft-pkaneria-lsr-multi-tlv intending to look TLVs that are 
> explicitly restricted to only a single entry?
> 
> G/
> 
> *From:*Lsr  *On Behalf Of *Tony Li
> *Sent:* Saturday, January 22, 2022 1:57 AM
> *To:* lsr 
> *Subject:* [Lsr] Fwd: New Version Notification for 
> draft-pkaneria-lsr-multi-tlv-00.txt
> 
> Hi all,
> 
> This draft attempts to codify existing practice. If you run out of 
> space in a TLV, generate another TLV of the same type and continue. 
> Ditto sub-TLVs and sub-sub-TLVs.
> 
> Comments welcome.
> 
> T
> 
> 
> 
> Begin forwarded message:
> 
> *From: *internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> 
> *Subject: New Version Notification for
> draft-pkaneria-lsr-multi-tlv-00.txt*
> 
> *Date: *January 21, 2022 at 4:55:01 PM PST
> 
> *To: *mailto:ant...@ietfa.amsl.com>>, "Chris
> Bowers" mailto:cbo...@juniper.net>>, "Les
> Ginsberg" mailto:ginsb...@cisco.com>>, "Parag
> Kaneriya" mailto:pkane...@juniper.net>>,
> "Shraddha Hegde"  <mailto:shrad...@juniper.net>>,  <mailto:t...@ietfa.amsl.com>>, "Tony Li"  <mailto:tony...@tony.li>>, "Tony Przygienda"  <mailto:p...@juniper.net>>
> 
> 
> A new version of I-D, draft-pkaneria-lsr-multi-tlv-00.txt
> has been successfully submitted by Tony Li, and posted to the
> IETF repository.
> 
> Name:draft-pkaneria-lsr-multi-tlv
> Revision:00
> Title:Multiple TLV Instances in IS-IS
> Document date:2022-01-21
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-00.txt
> <https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-00.txt>
> Status:
> https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
> <https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv
> 
> <https://datatracker.

Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

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

Hi Tony,

Interesting write-up. The proposal seems more operation friendly at first sight 
as the alternate solutions.

A while ago I was bumping into limitation of advertising a flex-algo FAD, and 
realized that only one is allowed and more seem to be forbidden by the draft 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo#section-5.1

   The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number, but
   a router MUST NOT advertise more than one IS-IS FAD Sub-TLV for a
   given Flexible-Algorithm.  A router receiving multiple IS-IS FAD Sub-
   TLVs for a given Flexible-Algorithm from the same originator MUST
   select the first advertisement in the lowest numbered LSP.

Is draft-pkaneria-lsr-multi-tlv intending to look TLVs that are explicitly 
restricted to only a single entry?

G/





From: Lsr  On Behalf Of Tony Li
Sent: Saturday, January 22, 2022 1:57 AM
To: lsr 
Subject: [Lsr] Fwd: New Version Notification for 
draft-pkaneria-lsr-multi-tlv-00.txt


Hi all,

This draft attempts to codify existing practice. If you run out of space in a 
TLV, generate another TLV of the same type and continue. Ditto sub-TLVs and 
sub-sub-TLVs.

Comments welcome.

T



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt
Date: January 21, 2022 at 4:55:01 PM PST
To: mailto:ant...@ietfa.amsl.com>>, "Chris Bowers" 
mailto:cbo...@juniper.net>>, "Les Ginsberg" 
mailto:ginsb...@cisco.com>>, "Parag Kaneriya" 
mailto:pkane...@juniper.net>>, "Shraddha Hegde" 
mailto:shrad...@juniper.net>>, 
mailto:t...@ietfa.amsl.com>>, "Tony Li" 
mailto:tony...@tony.li>>, "Tony Przygienda" 
mailto:p...@juniper.net>>


A new version of I-D, draft-pkaneria-lsr-multi-tlv-00.txt
has been successfully submitted by Tony Li, and posted to the
IETF repository.

Name:  draft-pkaneria-lsr-multi-tlv
Revision:  00
Title:  Multiple TLV Instances in IS-IS
Document date:   2022-01-21
Group:  Individual Submission
Pages:   7
URL:
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-00.txt
Status: https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-pkaneria-lsr-multi-tlv


Abstract:
  Emerging technologies are adding information into IS-IS TLVs at a
  steady pace while deployment scales are simultaneously increasing.
  This causes the contents of many critical TLVs to exceed the
  currently supported limit of 255 octets.  Extensions such as
  [RFC7356] require significant IS-IS changes that could help address
  the problem, but a less drastic solution would be beneficial.  This
  document codifies the common mechanism of extending the TLV space
  through multiple TLV instances.




The IETF Secretariat


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

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

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

Hi All,

wanted to record my +1 to the comment from Les on this matter.
(there is no intent or desire to open this discussion again)

G/

From: Lsr  On Behalf Of Jeff Tantsura
Sent: Friday, August 20, 2021 2:14 AM
To: Yingzhen Qu 
Cc: Les Ginsberg (ginsberg) ; Ron Bonica 
; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

we are going in rounds, +1 Les!
Cheers,
Jeff

On Aug 18, 2021, at 1:20 PM, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

Ron -

Indeed – it is long past the time when we should be focusing on the “big 
picture”.
I think Acee has stated it as succinctly as anyone – let me repeat for emphasis:

“The LSR WG developed ASLAs to cover usage of the link attributes (including 
metrics) for different applications and mitigate all the vagaries of the 
original TE link attribute specifications. ASLAs are implemented and deployed. 
I believe it would be a mistake to bifurcate the IGP standards with yet another 
way of encoding link attributes for different applications.”

ASLA is an architecture – one designed to assure that we can explicitly 
identify the set of applications using any link attribute . It is designed to 
be extensible both to new applications and to new attributes. It was long 
debated in the WG and underwent extensive review and is now standardized in 
RFCs 8919, 8920. It has been implemented and deployed and forms the basis of 
interoperable implementations.

Now you (and others) decide to invent a new attribute. The attribute certainly 
can be advertised using ASLA, but instead of acknowledging the existence of the 
ASLA architecture and defining the new attribute to use ASLA, you decide that 
maybe if we advertise this attribute in some new way there might be some modest 
advantages. This ignores the consequences of having to implement attribute 
specific encoding rules in order to map attributes to applications. These 
consequences include greater code complexity and higher probability of 
interoperability issues.

And, based on your list of attributes below, what have we to look forward to? 
More attribute specific encoding rules leading to even greater code complexity 
and greater chance of interoperability problems it would seem.

Look, you haven’t convinced me that your alternative proposals are “better”. 
But even if they were, it would require a much greater benefit than you are 
claiming to justify discarding the architecture that is designed to fully 
address the association of link attributes and the applications which use them.

I don’t expect to convince you – and you have not convinced me – and we 
probably never will agree. But since it is clear that ASLA does work for all 
the cases that have been mentioned in this and related threads, I think this 
discussion is a waste of WG time.

It is time to close this discussion.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Ron 
Bonica
Sent: Tuesday, August 17, 2021 11:21 AM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

Acee,

So, let us discuss whether there is a good reason for 
draft-ietf-lsr-flex-algo-con to specify ASLA !

Link attributes are different from application configuration information. Link 
attributes are properties of a link.  They are independent of the applications 
that use them. The following are examples:


  *   Total physical bandwidth
  *   Number of LAG elements
  *   Bandwidth of smallest lag member
  *   Latency

Link attributes do not benefit from ASLA encoding because they are not 
application specific.

Application configuration information constrains the behavior of an 
application. It can apply to:


  *   The application and a link
  *   The application only

Bandwidth reservation applies to an application and a link. For example, a link 
may advertise that it has:


  *   X Gbps available for RSVP-TE reservations
  *   Y Gbps available for SR Policy reservations
  *   Z Gbps available for TI-LFA reservations

This class of configuration information clearly benefits from ASLA encoding, 
because it is applicable to both the application and the link.

Some applications (e.g., Flexalgo) can be configured to use a variety of link 
attributes in SPF calculation. No matter how they acquire this configuration 
information, it MUST be the same at each node. Otherwise, routing loops may 
result. Configuration options are:


  1.  Configure this information on each link and advertise link attributes 
with ASLA
  2.  Configure this information on each node that runs the application
  3.  Configure this information in a few central places and advertise it to 
all other nodes. The advertisement is not associated with a link. Flexalgo uses 
the FAD in this manner.

Neither Option 1 nor Option 2 is very appealing, because it requires 
configuration on each 

Re: [Lsr] Generic metric: application-specific vs application-independent

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

A little late in the discussion... (PTO events do happen)

a quick opinion on the below discussion on whether Generic metric sub-tlv 
should be encoded on a ASLA or not.
For me, it depends on how the metric for the corresponding metric-type is 
obtained and if it can be configured (static).
It doesn’t make sense to have Application specific values if a particular 
metric is obtained only dynamically, for eg, dynamically measured delay is 
going to be same for all applications.
On the contrary, te-metric can be configured, and we can in principle configure 
different values for different applications.

My opinion is that if any of the metric-types in the Generic metric sub-tlv can 
be configured, it should be inside the ASLA.

G/

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Friday, July 30, 2021 9:42 AM
To: Shraddha Hegde ; Les Ginsberg 
(ginsberg) ; Tony Li 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent

Shraddha,

On 30/07/2021 06:53, Shraddha Hegde wrote:
> Operators have built their networks with link attributes
> 
> being configured and used by any application. For example
> 
> igp-metric is used by ISIS, then came LDP that used same igp-metric,
> 
> RSVP could also use igp-metric. Then came ISIS-SR and SR-TE
> 
> and even flex-algo. All these applications could use the same igp-metric.
> 
> The networks have evolved like this for 20-30 years.
> 
> If an operator wants to design his network for this kind of
> 
> network evolution with generic metric going forward, ASLA does not
> 
> currently provide an effective solution. 

please be more specific as to what exactly "ASLA does not currently provide an 
effective solution" for.

> ASLA currently has limitations
> 
> that make it more complex than necessary for operators who want to
> 
> evolve their networks this way.

above seems more like your opinion than the fact. I have not seen any evidence 
that would prove the above statement.


> 
> I am working on a draft to propose improvements to ASLA to
> 
> make this kind of evolution less complex. I'll post a draft
> 
> soon that will describe limitations of ASLA in its current form
> 
> along with proposed improvements.


hard to comment on something that does not exist.


> 
> I would still like to hear about use cases that require
> 
> generic metric to be applications-specific and cannot be solved with
> 
> application-independent generic metric.

it has been explained on the list multiple times.


thanks,
Peter


> 
> Rgds
> 
> Shraddha
> 
> Juniper Business Use Only
> 
> *From:* Les Ginsberg (ginsberg) 
> *Sent:* Thursday, July 29, 2021 2:00 AM
> *To:* Tony Li 
> *Cc:* lsr@ietf.org; Shraddha Hegde 
> *Subject:* RE: [Lsr] Generic metric: application-specific vs 
> application-independent
> 
> *[External Email. Be cautious of content]*
> 
> Tony –
> 
> You ask very important questions – but – as Acee has answered in a 
> subsequent email – all of these questions were openly debated in the WG 
> during the work on what became RFC8919/8920. This debate was 
> contentious, took years, and the WG eventually reached consensus on what 
> became the two RFCs.
> 
> If every time a new attribute is defined we reopen the original debate, 
> then we will never move forward and we will have great difficulty in 
> deploying interoperable implementations.
> 
> I can respect that you might have preferred a different conclusion on 
> the part of the WG – but I hope you will also acknowledge that this is 
> now a resolved issue and we need to move forward following the existing 
> RFCs.
> 
> Parenthetically, I do believe that answers to your questions can be 
> found in the RFCs. The answers may not satisfy you – but we did attempt 
> to include the context which drove the ASLA solution.
> 
> Thanx.
> 
>      Les
> 
> *From:* Lsr mailto:lsr-boun...@ietf.org>> *On 
> Behalf Of *Tony Li
> *Sent:* Wednesday, July 28, 2021 1:06 PM
> *To:* Les Ginsberg (ginsberg)  >
> *Cc:* lsr@ietf.org ; Shraddha Hegde 
>  >
> *Subject:* Re: [Lsr] Generic metric: application-specific vs 
> application-independent
> 
> Les,
> 
> ASLA exists to support the advertisement of attributes which can be
> used in application specific ways.
> 
> Why do we need separate and different copies of attributes for different 
> applications?
> 
> The SRLG tries to capture the risk relationships between multiple links. 
> Those relationships don’t change depending on the application.
> 
> Link attributes don’t require the variability that ASLA provides, and 
> the overhead is high.  How does this cost/benefit ratio make sense?
> 
> In any particular deployment case, a given attribute advertisement
> might be used by one app, multiple apps, or all apps.
> 
> ASLA allows to unambiguously support all of these cases with a
> single advertisement encoding format.
> 

Re: [Lsr] Proposed Errata for RFCs 8919/8920

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

Another item of ambiguity is whether "wildcarding" applies also to the ISIS 
TE-Appl-Spec-SRLG TLV.
It seems that the RFC8919 does not specify it.
Note: for OSPF the wildcarding also applies to SRLG info because it is 
transported via the same container TLV as the other TE attributes.

Example 1
TE-IS-NBRs TLV
 Link x
  ASLA TLV
  SABML 0, UDABML 0 (= All Appl)
  TE-Metric 20
TE-Appl-Spec-SRLG TLV
Link x
SABML 1, UDABML 0, Bitmap Flex-Algo
   SRLG 1 2 3

Should TE-Metric 20 be used for Flex-Algo or not ?
In other words, is the wildcard ASLA TLV overruled by the specific 
TE-Appl-Spec_SRLG TLV or not ?

Example 2
Maybe this is an invalid example if wildcarding does not apply for the 
TE-Appl-SRLG TLV.
TE-IS-NBRs
 Link x
  ASLA TLV
  SABML 1, UDABML 0, Bitmap Flex-Algo
  TE-Metric 20
TE-Appl-Spec-SRLG
Link x
SABML 0, UDABML 0 (= All Appl)
   SRLG 1 2 3

Should SRLG 1 2 3 be used for Flex-Algo or not ?

What is your opinion ?

G/


From: Shraddha Hegde 
Sent: Wednesday, June 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter 
(Nokia - BE/Antwerp) 
Subject: RE: Proposed Errata for RFCs 8919/8920

Hi,

I think that there may still be some ambiguity arising from the text below due 
to the fact that
There are attributes such as maximum-link-bandwidth which have special 
behaviour mentioned in later sections.

"Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used."


For example, If max link bandwidth attribute comes in a
Zero length SABM & UDABM and we have a Flex-algo specific ASLA
that does not have the max-link-bandwidth advertised, can
Flex-algo use max-link-bandwidth attribute?

My interpretation from modified text for ISIS is that,  it cannot use it.
I think there is no harm in re-iterating in order to avoid people reading is 
differently.

Link attributes MAY be advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications.
Such advertisements MUST be used by standard applications and/or user defined 
applications when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Bit set 
are present for a given link. Otherwise, such advertisements MUST NOT be used.
In other words,
When an application specific link Attribute sub-TLV is advertised with one or 
more specific
standard application or user defined application bits set, all link attributes 
that are allowed in ASLA MUST
be used from the ASLA sub-TLVs having that specific application bit set.
For the purposes of such applications, link attributes MUST NOT be used from
ASLA sub-TLV with zero SABM & UDABM length.


Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Tuesday, June 15, 2021 8:55 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Van De Velde, 
Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Subject: [Lsr] Proposed Errata for RFCs 8919/8920

[External Email. Be cautious of content]


Folks -



Recent discussions on the list have highlighted some unintentional ambiguity in 
how ASLA advertisements are to be used. Please see 
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/__;!!NEt6yMaO-gk!RK_eZNNu1y0aJvAqIaNwHTIFAjHWFJwW1UqyOO8ACxB0kof3jmD_dRkiPkbVLJyA$>



The following proposed Errata address this ambiguity and aligns language in the 
two RFCs.



We welcome comments on the proposed Errata before officially filing them.



  Les and Peter


Errata Explanation

Both RFC 8919 and RFC 8920 define advertising link attributes with zero length 
Standard Application Bit Mask (SABM) and zero length User Defined Application 
Bit Mask (UDABM)
as a means of advertising link attributes that can be used by any application. 
However, the text uses the word "permitted", suggesting that the use of such 
advertisements is "optional".
Such an interpretation could lead to interoperability issues and is not what 
was intended.

The replacement text below makes explicit the specific conditions when such 
advertisements MUST be used and the specific conditions under which they MUST 
NOT be used.

RFC 8919 Section 4.2:

O

Re: [Lsr] draft-ietf-lsr-flex-algo

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

Thanks for this interesting discussion. May I show a simple example to clarify 
a confusion, and I hope this helps to clarify implementation behavior:

Example: 2 ASLA TLV's are received for 1 link:

  *   ASLA TLV for all applications (SABML AND UDBML = 0) containing TE-Metric 
5 and Admin Group 7
  *   ASLA TLV with Flex-Algo bit set containing TE-Metric 10

What would the implementation have to follow?
Option 1: TE-Metric 10 used for Flex-algo, while Admin-Group 7 is not used. 
I.e. the overruling is done on ASLA TLV basis.
Option 2: TE-Metric 10, Admin-Group 7 have to be used for Flex-Algo. I.e. the 
overruling is done on a per attribute basis.

if you read the related ISIS and OSPF RFC's, they seem to contradict (as 
pointer out by Bruno Decraene):

  *   ISIS seems to expect Option 1
  *   OSPF seems to expect Option 2

Now, if we look all the way back to a year ago (12 June 2020):
https://mailarchive.ietf.org/arch/msg/lsr/TsjdMZmegf1SDO5B-X7y04mkgCM/
Then that conclusion of the DISCUSS seems to indicate Option 2.

snip
An application specific advertisement (Application Identifier Bit
Mask with a matching Application Identifier Bit set) for an attribute
MUST always be preferred over the advertisement of the same attribute
with the zero length Application Identifier Bit Masks for both
standard applications and user defined applications on the same link.
End Snip

This reads as option 2 seems to be the implementation of choice and overruling 
is done on a per attribute basis.

A fine question is what Les specifically means with "matching ASLA 
advertisements" ?
That can easily be read as the expected result is Option 1.

Long story short, what is the expected implementation behavior?
The DISCUSS indicate behavior as Option 2 (the overruling is done on a per 
attribute basis.)

G/

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Friday, June 4, 2021 11:03 AM
To: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi all,

I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1]

FlexAlgo is distributed routing computation so it's required that all routers 
use exactly the same data to compute the routes/SPF.

FlexAlgo is clear that ASLA MUST be used:

"Link attribute advertisements that are to be used during Flex-

   Algorithm calculation MUST use the Application-Specific Link

   Attribute (ASLA) advertisements defined in 
[RFC8919] or 
[RFC8920],"

However ASLA provides multiple ways to advertise IGP attributes and does not 
seem precise enough in its specification.
"If link attributes are advertised associated with zero-length Application 
Identifier Bit Masks for both standard applications and user-defined 
applications, then any standard application and/or any user-defined application 
is permitted to use that set of link attributes"

My issue is the use of the term "permitted" which

  1.  is not a normative keyword
  2.  IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure 
a consistent SPF.



One example of issue is when FlexAlgo uses a metric different from the IGP 
(e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with 
zero-length Bit Mask.
- If one node uses this TE-metric (since it is permitted to) it includes that 
link in its SPF
- If another node does not use this TE-metric (since it is not required to) it 
prunes that link from its SPF
I think it's self-evident that we would end up with a permanent routing loop.

Ideally, I would probably have preferred ALSA to be specific about the 
behaviour but ASLA is already published as RFC so it's a bit late
So at this point, I think that the burden is on FlexAlgo to specify the precise 
behaviour as a MUST in section 12. [2]

The smallest change from FlexAlgo draft standpoint may be to _require_ the use 
of the ASLA _with the X-Flag set_ . But I'm fine with whatever interoperable 
behaviour (well for me, ideally I'd prefer the behaviour already implemented by 
the implementations that I've deployed ;-) but that would be a selfish 
requirement).

Note that there are existing implementations and this would impact them. That 
been said, we do need the interop behaviour so if there are already 
inconsistent behaviours, some implementations will need to be changed (and 
hence become non interoperable with themselves)

Thanks,
Regards,
--Bruno


[1] https://www.rfc-editor.org/rfc/rfc8919.html
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12


_



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 

[Lsr] WGLC for draft-ietf-lsvr-bgp-spf-13 (to end June 3, 2021)

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

Hi All,





The author team together with AD have been working hard on this document and 
made significant enhancements to this document.





The LSVR WG starts a working group last call for "draft-ietf-lsvr-bgp-spf-13". 
Please send your comments to the LSVR list before Thursday June 3, 2021.



https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/





This WGLC is cross-posted to IDR and LSR WG. All feedback and discussions 
should happen on the LSVR WG mailer.





Authors, please reply indicating if you're aware of any relevant IPR.



All, Please advice if you are aware of an implementation or are aware of 
relevant IPR.





Brgds,

Gunter & Victor

LSVR WG co-chairs

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

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

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

Hi Peter, All,

Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the 
prefix-attribute tlv is mandatory when a locator is redistributed?

Why? 
*When calculating a LFA for an SRv6 End.SID we better know if the locator has 
been redistributed or not for a correct operation.

Reasoning:
* A locator has the D bit. This one is set when we redistribute from L2 to L1.
** So this end-sid will not be used as we know that it is redistributed.

* In the other direction (L1-L2), we only know that a locator is redistributed 
from L1 to L2 if the prefix-attribute sub-tlv is advertised.
** This means if the operator does not configure advertisement of the 
prefix-attribute tlv, ISIS could potentially use an end-sid which does not 
terminate on the expected  node.

* Compared to sr-mpls, a prefix-sid has the R flag indicating it is 
redistributed.
* We don't have that for locator end-sids.

Relevant snip from " draft-ietf-lsr-isis-srv6-extensions"

7.1.  SRv6 Locator TLV Format

   The SRv6 Locator TLV has the following format:

   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|R|R|R|R|MT ID  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Type: 27

Length: variable.

R bits: reserved for future use. They MUST be
set to zero on transmission and MUST be ignored on receipt.

MT ID: Multitopology Identifier as defined in [RFC5120].
Note that the value 0 is legal.

   Followed by one or more locator entries of the form:

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Metric   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Flags   |  Algorithm|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Loc Size | Locator (variable)...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Sub-TLV-len  | Sub-TLVs (variable) . . . |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Metric: 4 octets. As described in [RFC5305].

Flags: 1 octet. The following flags are defined

  0
  0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |D|Reserved |
 +-+-+-+-+-+-+-+-+

 where:
   D-flag: Same as described in section 4.1. of [RFC5305].


G/

-Original Message-
From: Lsr  On Behalf Of The IESG
Sent: Thursday, April 22, 2021 10:14 PM
To: IETF-Announce 
Cc: lsr@ietf.org; lsr-cha...@ietf.org; cho...@chopps.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; aretana.i...@gmail.com
Subject: [Lsr] Last Call:  (IS-IS 
Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to 
consider the following document: - 'IS-IS Extension to Support Segment Routing 
over IPv6 Dataplane'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final 
comments on this action. Please send substantive comments to the 
last-c...@ietf.org mailing lists by 2021-05-07. Exceptionally, comments may be 
sent to i...@ietf.org instead. In either case, please retain the beginning of 
the Subject line to allow automated sorting.

Abstract


   The Segment Routing (SR) allows for a flexible definition of end-to-
   end paths by encoding paths as sequences of topological sub-paths,
   called "segments".  Segment routing architecture can be implemented
   over an MPLS data plane as well as an IPv6 data plane.  This document
   describes the IS-IS extensions required to support Segment Routing
   over an IPv6 data plane.

   This documents updates RFC 7370 by modifying an existing registry.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/


The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3796/
   https://datatracker.ietf.org/ipr/4486/






___
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] Clarification on inconsistency between RFC7794 and draft-ietf-lsr-isis-srv6-extensions

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

Thanks Peter.

With algo-0 SRv6, then after the draft is updated, it will be allowed that the 
attribute flags are none-identical between locator-tlv (27) and TLV236/237? 
Is that understanding correct? 

G/


-Original Message-
From: Peter Psenak  
Sent: Wednesday, February 24, 2021 16:39
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org
Cc: lsr@ietf.org
Subject: Re: Clarification on inconsistency between RFC7794 and 
draft-ietf-lsr-isis-srv6-extensions

Hi Gunter,

On 24/02/2021 07:24, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
> 
> I’m am trying to clarify a potential inconsistency between RFC7794 and 
> draft-ietf-lsr-isis-srv6-extensions.
> 
> draft-ietf-lsr-isis-srv6-extensions says that we should advertise 
> identical prefix-attribute tlv for the ipv6 reachability tlv and for 
> the locator tlv.

yes, for algo 0 only.

> 
> RFC7794 document says that we should not set the X flag in case of 
> ipv6 routes because the ipv6 reachability tlv already has an external 
> indication.
> 
> Can you advise.
> 
>  1. draft-ietf-lsr-isis-srv6-extensions
> 
> The Prefix Attribute Flags Sub-TLV can be carried in the SRv6 Locator
> 
>     TLV as well as the Prefix Reachability TLVs.  When a router
> 
>     originates both the Prefix Reachability TLV and the SRv6 Locator 
> TLV
> 
>     for a given prefix, and the router is originating the Prefix
> 
>     Attribute Flags Sub-TLV in one of the TLVs, the router SHOULD
> 
>     advertise identical versions of the Prefix Attribute Flags Sub-TLV 
> in

For locator TLV, the is X-flag obtained from Prefix Attribute Flags Sub-TLV, 
unlike the TLVs 236 and 237. I will add the text to clarify that difference.

thanks,
Peter

> 
> both TLVs.
> 
>  2. RFC7794
> 
> Prefix Attribute Flags
> 
>   Type:   4
> 
>   Length: Number of octets of the Value field.
> 
>   Value:
> 
>    (Length * 8) bits.
> 
>     0 1 2 3 4 5 6 7...
> 
>    +-+-+-+-+-+-+-+-+...
> 
>    |X|R|N|  ...
> 
>    +-+-+-+-+-+-+-+-+...
> 
>     Bits are defined/sent starting with Bit 0 defined below.  
> Additional
> 
>     bit definitions that may be defined in the future SHOULD be 
> assigned
> 
>     in ascending bit order so as to minimize the number of bits that 
> will
> 
>     need to be transmitted.
> 
>     Undefined bits MUST be transmitted as 0 and MUST be ignored on
> 
>     receipt.
> 
>     Bits that are NOT transmitted MUST be treated as if they are set 
> to 0
> 
>     on receipt.
> 
>     X-Flag:  External Prefix Flag (Bit 0)
> 
>    Set if the prefix has been redistributed from another protocol.
> 
>    This includes the case where multiple virtual routers are
> 
>    supported and the source of the redistributed prefix is another
> 
>    IS-IS instance.
> 
>    The flag MUST be preserved when leaked between levels.
> 
>    In TLVs 236 and 237, this flag SHOULD always be sent as 0and MUST
> 
>    be ignored on receipt.  This is because there is an existing X
> 
>    flag defined in the fixed format of these TLVs as specified in
> 
> [RFC5308 <https://tools.ietf.org/html/rfc5308>] and [RFC5120 
> <https://tools.ietf.org/html/rfc5120>].
> 
> G/
> 

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

[Lsr] Clarification on inconsistency between RFC7794 and draft-ietf-lsr-isis-srv6-extensions

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

Hi Peter, All,

I'm am trying to clarify a potential inconsistency between RFC7794 and 
draft-ietf-lsr-isis-srv6-extensions.

draft-ietf-lsr-isis-srv6-extensions says that we should advertise identical 
prefix-attribute tlv for the ipv6 reachability tlv and for the locator tlv.

RFC7794 document says that we should not set the X flag in case of ipv6 routes 
because the ipv6 reachability tlv already has an external indication.

Can you advise.


  1.  draft-ietf-lsr-isis-srv6-extensions



The Prefix Attribute Flags Sub-TLV can be carried in the SRv6 Locator

   TLV as well as the Prefix Reachability TLVs.  When a router

   originates both the Prefix Reachability TLV and the SRv6 Locator TLV

   for a given prefix, and the router is originating the Prefix

   Attribute Flags Sub-TLV in one of the TLVs, the router SHOULD

   advertise identical versions of the Prefix Attribute Flags Sub-TLV in

   both TLVs.




  1.  RFC7794


Prefix Attribute Flags

 Type:   4

 Length: Number of octets of the Value field.

 Value:



  (Length * 8) bits.



   0 1 2 3 4 5 6 7...

  +-+-+-+-+-+-+-+-+...

  |X|R|N|  ...

  +-+-+-+-+-+-+-+-+...



   Bits are defined/sent starting with Bit 0 defined below.  Additional

   bit definitions that may be defined in the future SHOULD be assigned

   in ascending bit order so as to minimize the number of bits that will

   need to be transmitted.



   Undefined bits MUST be transmitted as 0 and MUST be ignored on

   receipt.



   Bits that are NOT transmitted MUST be treated as if they are set to 0

   on receipt.



   X-Flag:  External Prefix Flag (Bit 0)

  Set if the prefix has been redistributed from another protocol.

  This includes the case where multiple virtual routers are

  supported and the source of the redistributed prefix is another

  IS-IS instance.



  The flag MUST be preserved when leaked between levels.



  In TLVs 236 and 237, this flag SHOULD always be sent as 0 and MUST

  be ignored on receipt.  This is because there is an existing X

  flag defined in the fixed format of these TLVs as specified in

  [RFC5308] and 
[RFC5120].
G/

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

Re: [Lsr] Link Data value for Multi-area links

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

The oddnes is that the architecture decision in RFC5185 to select 
remote-ip-address instead of local-ip-address for the ‘Link Data’ is making 
things much more complicated.
I am surprised to see that using the remote-ip-address is seen as the ‘better’ 
choice as selecting local-ip-address. To me it seems as a worse choice.

A question that was asked: How router will be able to match Link TLV (RFC 3630) 
to corresponding Link in Router LSA?

Answer:
For unnumbered links we can match Link TLV with Router TLV using the IfIndex 
when there is no stub type 3 link (=easy)
For numbered:

  1.  we must first look if the there is a stub type 3 link
  2.  If stub type 3 exists, then the RFC3630 local ip address must be used to 
identify the correspond link within the router TLV to the neighbor
  3.  If the stub type 3 link did not exist in Router TLV link, then the maybe 
the link is unnumbered, and we try to match upon IfIndex… This may give a match 
or no match
  4.  If there is no match, then maybe the link is MADJ and we must use the 
RFC3630 remote IP address to match upon the Link Data
  5.  = over-complex. (If we used  for RFC5185 ‘Link Data = local ip address’ 
then (2) would given answer directly)

In addition, for a router it is much simpler to learn and advertise 
local-ip-address in Router LSAs then using a remote-ip-address.
I also believe that if we want to search something in TEDB after receiving a TE 
Link TLV. How can we identify from the TE Link TLV if multi-area or not 
multi-area? If we can not, then how can we create the correct key?

Looking at the above, the choice of using remote-ip-address for RFC5185 Link 
Data seems not the best design that we can do, and is adding OSPF complexity 
without benefits.

Should this not be corrected in RFC5185 and simply use local-ip-address instead 
of the remote-ip-address for Multi-area Link Data and avoid the additional 
unnecessary complexity the current RFC for numbered links?

Brgds,
G/


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Monday, November 30, 2020 18:01
To: Alexander Okonnikov ; Peter Psenak (ppsenak) 

Cc: lsr@ietf.org
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Alex,

Multi-Area interface disambiguation is required to support the OSPF MIB as 
specified in RFC 4750. The table indexing doesn’t include the area. For example:

--  OSPF Interface Table

  ospfIfTable OBJECT-TYPE
   SYNTAX   SEQUENCE OF OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF Interface Table describes the interfaces
  from the viewpoint of OSPF.
  It augments the ipAddrTable with OSPF specific information."
   REFERENCE
  "OSPF Version 2, Appendix C.3  Router interface
  parameters"
   ::= { ospf 7 }

  ospfIfEntry OBJECT-TYPE
   SYNTAX   OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF interface entry describes one interface
  from the viewpoint of OSPF.

  Information in this table is persistent and when this object
  is written the entity SHOULD save the change to non-volatile
  storage."
   INDEX { ospfIfIpAddress, ospfAddressLessIf }
   ::= { ospfIfTable 1 }

Note that if you really want to support this optimally, you could use a 
separate subnet pre-area and have adjacencies on secondary addresses. My 
Redback/Ericsson implementation allowed for this.

Thanks,
Acee


From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>
Date: Monday, November 30, 2020 at 5:27 AM
To: "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Peter,

30 нояб. 2020 г., в 12:56, Peter Psenak 
mailto:ppse...@cisco.com>> написал(а):

Hi Alex,

On 27/11/2020 13:49, Alexander Okonnikov wrote:
Hi Peter,
Which kind of ambiguity is meant? In case of numbered point-to-point each link 
has its own unique IP address, so there is no ambiguity.
Per my understanding this problem has appeared due to follow reasons:
1) In old versions of the draft (up to -05) it was proposed that multi-area 
links are treated as unnumbered. ifIndex to be encoded in Link Data field, 
irrespectively whether interface has its own IP address (numbered) or borrow it 
(unnumbered);
2) From -06 to -08 multi-area links are still treated as unnumbered, but if 
interface is numbered, then IP address of the neighbor (rather than local one) 
to be encoded into Link Data, in order to make the link look like unnumbered;
3) In version -09 of the draft and in RFC 5185 itself there is no more mentions 
that multi-area link to be treated as unnumbered. Rather, another approach is 
used - if router's interface is numbered, then link is also numbered; if 
router's interface is unnumbered, then link is unnumbered. The rule 

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

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

Flex-algo application MUST be able to encode flex-algo link attributes using 
valid ASLA for flex-algo.
Flex-algo application MUST be able to decode flex-algo link attributes using 
valid ASLA for flex-algo.

A valid IS-IS ASLA may be encoded with L-bit SET or UNSET. The setting of L-bit 
is a choice from the flex-algo application implementation and/or encoding 
capabilities.
A flex-algo node MUST NOT make assumption on the L-bit encoding capabilities of 
any other flex-algo, and SHOULD expect to receive valid ASLA encodings from 
other flex-algo nodes.

I agree with Peter to adhere flex-algo implementations as documented in latest 
WG document. 

G/

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Tuesday, September 8, 2020 10:53
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Shraddha,

when documents get adopted by the WG when they are still subject to changes. 
Based on WG feedback and implementation experience the drafts evolve to the 
point where they are considered mature and stable. Then they are ready to 
become RFCs and be used as the standard definition to be followed by 
interoperable implementations. Earlier versions are simply steps on the way.

For whatever reason, you and your company have apparently chosen NOT to have 
your flex-algo implementation adhere to the draft as it has been defined in the 
latest WG document. That is your choice. But I do not think you have the right 
to ask the IETF to document this proprietary choice and by doing so imply that 
this is a supported variation endorsed by the IETF.

thanks,
Peter






On 08/09/2020 05:43, Shraddha Hegde wrote:
> Peter,
> 
> 
> Thanks for the conclusion on adding L-bit clarification in the 
> draft-ietf-lsr-flex-algo.
> 
> Snip to open comments.
> 
>> Note that earlier versions of this document did not mandate use of 
>> ASLA TLVs and hence may not inter-operate with early implementations that 
>> use legacy advertisements."
> 
>   >it is not true that "earlier versions of this document" did not 
> mandate ASLA.
> 
>   
> >https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-
>   >gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$ , 
> which only supported the >  >include/exclude Admin Groups, clearly stated:
> 
> https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
> https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/
> 
> https://mailarchive.ietf.org/arch/browse/lsr/?q=LSR%20Working%20Group%
> 20Adoption%20Poll%20for%20Flex%20Algorithm%20Drafts
> 
> The above two drafts were polled for WG adoption. These two drafts did not 
> have any reference to te-app draft.
> 
> There was no discussion in the WG about ASLA TLV during the adoption call. 
> When the WG adopted draft was posted, that merged the ISIS and OSPF drafts 
> and the non-backward compatible text mandating ASLA TLV was introduced. The 
> link to this draft, you have copied in the mail above.
> 
> 
> I think it is fair to warn the operators on the possible inter-op issues this 
> could cause.
> I would like to see the above sentence added to the draft.
> 
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Thursday, September 3, 2020 1:25 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Shraddha,
> 
> On 03/09/2020 05:39, Shraddha Hegde wrote:
>> Peter,
>>
>> In order to make the document clearer on this point, I would like the 
>> text below to be added to section 11 to make it explicit that setting the 
>> L-bit is valid for flex-algo for ISIS.
>>
>> =
>> Section 11.
>>
>> “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 
>> of [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST 
>> use legacy advertisements for that link. Flex algorithm application 
>> MUST support sending and receiving link attributes with ASLA TLV having 
>> L-bit set.
> 
> 
> I can add the above, although, it's clear from the draft-ietf-isis-te-app 
> that L-bit with legacy advertisement MAY be used for any app.
> 
>>
>> Note that earlier versions of this document did not mandate use of 
>> ASLA TLVs and hence may not inter-operate with early implementations that 
>> use legacy advertisements."
> 
> it is not true that "earlier versions of this document" did not mandate ASLA.
> 
> 

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

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

I think that some misunderstanding comes from a different definition of " 
LEGACY ADVERTISEMENTS" between section 4.2 and 6.1

In section 4.2:
LEGACY ADVERTISEMENTS means that *ASLA is used* and point to the attributes 
found in legacy TLVs for example EAG, Delay and TE-metric

In section 6.1:
LEGACY ADVERTISEMENTS means that *ASLA is NOT used* and allows RSVP-TE, 
SR-Policy and LFA to interoperate between systems that do not, and do, support 
ASLA

Taking this understanding to flex-algo:
* Interop: traditionally we use the L-bit=SET for application interoperability 
when not all nodes understand valid ASLA encoding. 
* Interop: by design of flex-algorithm technology, we mandate ASLA encoding. No 
interop issues should exist with nodes not understanding ASLA encodings.
* Why would a flex-algo node, ever, advertise legacy TLVs for flex-algo 
attributes? There seems no use-case and no logic for such. 
* OSPF has no existing L-bit

For flex-algo simplicity, we could agree that legacy attribute advertisements 
MUST NOT be used and agree that flex-algo ASLA L-bit MUST be UNSET 
(This is unrelated that flex-algo ASLA with L-bit SET is semantically a valid 
ASLA. This also simplifies and align ISIS and OSPF routing protocol behavior. 
It reduce interop issues footprint with systems not supporting ASLA.)

G/






-Original Message-
From: Peter Psenak  
Sent: Thursday, September 3, 2020 12:02
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Selderslaghs, Rudy (Nokia - BE/Antwerp) ; Shraddha 
Hegde ; olivier.dug...@orange.com; tony...@tony.li; 
Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Gunter,

On 03/09/2020 11:53, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
> 
> Let me chime in.
> 
> When the L-bit is set in an ASLA TLV, then for all applications marked, 
> indeed only legacy attributes can be used.
> Of course an ASLA TLV with the L-bit set is a valid ASLA advertisement. That 
> is not the point.
> 
> Read the text in chapter 4.2:
> 
>>  When the L-flag is set in the Application Identifier Bit Mask, all of
>>  the applications specified in the bit mask MUST use the legacy
>>  advertisements for the corresponding link found in TLVs 22, 23, 25,
>>  141, 222, and 223 or TLV 138 or TLV 139 as appropriate.
> 
> This clearly says that when the L-bit is set, the LEGACY ADVERTISEMENTS have 
> to be used.
> However chapter 6.1 is saying that legacy advertisements can only be used for 
> RSVP-TE, SR-Policy and LFA.

where? Please point me to the text.

If you are referring to the text:

"New applications that future documents define to make use of the 
advertisements defined in this document MUST NOT make use of legacy 
advertisements."

then it is NOT preventing L-bit with legacy advertisement for new apps, because 
ASLA with L-bit in combination with legacy advertisement is not considered as 
legacy advertisement, but as a valid ASLA advertisement.


> 
> So in my opinion the draft is saying the opposite and legacy advertisements 
> MUST NOT be used for flex-algo.

again, L-bit with legacy advertisement is NOT a legacy advertisement. It is 
ASLA advertisement.

> Hence, I suggest that we should make it explicit clear that L-bit set for 
> flex-algo is MUST NOT be allowed.

L-bit is allowed with any app, including the flex-algo.

thanks,
Peter

> 
> G/
> 
> 
> 
> 
> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 11:19
> To: Selderslaghs, Rudy (Nokia - BE/Antwerp) 
> ; Peter Psenak 
> ; Shraddha Hegde 
> ; olivier.dug...@orange.com; tony...@tony.li; 
> Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> 
> Hi Rudy,
> 
> On 03/09/2020 11:01, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:
>> Hi Peter,
>>
>> My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit 
>> set to 1, cannot be used for Flex-Algo.
> 
> no, that is not correct.
> 
>> This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 
>> 6.1.
> 
> no.
> 
>>
>> >From chapter 6.1 Use of Legacy advertisements:
>>  ...
>>  New applications that future documents define to make use of the
>>  advertisements defined in this document MUST NOT make use of legacy
>>  advertisements.  This simplifies deployment of new applications by
>>  eliminating the need to support multiple ways t

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

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

Hi Peter, All,

Let me chime in.

When the L-bit is set in an ASLA TLV, then for all applications marked, indeed 
only legacy attributes can be used.
Of course an ASLA TLV with the L-bit set is a valid ASLA advertisement. That is 
not the point.

Read the text in chapter 4.2:

> When the L-flag is set in the Application Identifier Bit Mask, all of
> the applications specified in the bit mask MUST use the legacy
> advertisements for the corresponding link found in TLVs 22, 23, 25,
> 141, 222, and 223 or TLV 138 or TLV 139 as appropriate.

This clearly says that when the L-bit is set, the LEGACY ADVERTISEMENTS have to 
be used.
However chapter 6.1 is saying that legacy advertisements can only be used for 
RSVP-TE, SR-Policy and LFA.

So in my opinion the draft is saying the opposite and legacy advertisements 
MUST NOT be used for flex-algo.
Hence, I suggest that we should make it explicit clear that L-bit set for 
flex-algo is MUST NOT be allowed.

G/




-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp) ; 
Peter Psenak ; Shraddha Hegde 
; olivier.dug...@orange.com; tony...@tony.li; Robert 
Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Rudy,

On 03/09/2020 11:01, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:
> Hi Peter,
> 
> My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit set 
> to 1, cannot be used for Flex-Algo.

no, that is not correct.

> This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 
> 6.1.

no.

> 
>>From chapter 6.1 Use of Legacy advertisements:
> ...
> New applications that future documents define to make use of the
> advertisements defined in this document MUST NOT make use of legacy
> advertisements.  This simplifies deployment of new applications by
> eliminating the need to support multiple ways to advertise attributes
> for the new applications.

ASLA with L-bit pointing to legacy TLV is NOT considered legacy advertisement. 
It is valid ASLA advertisement.


> 
> Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy 
> advertisements":

no. It says that if L-flag is set, all apps mentioned in the bitmask 
MUST use the legacy advertisement to derive the value of the attribute. 
It does NOT say that ASLA TLV with L-bit set means "using legacy 
advertisements". It does not.

thanks,
Peter

> ...
> When the L-flag is set in the Application Identifier Bit Mask, all of
> the applications specified in the bit mask MUST use the legacy
> advertisements for the corresponding link found in TLVs 22, 23, 25,
> 141, 222, and 223 or TLV 138 or TLV 139 as appropriate.
> 
> Regards,
> Rudy
> 
> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 9:55 AM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; Acee 
> Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
> 
> Hi Shraddha,
> 
> On 03/09/2020 05:39, Shraddha Hegde wrote:
>> Peter,
>>
>> In order to make the document clearer on this point, I would like the
>> text below to be added to section 11 to make it explicit that setting the 
>> L-bit is valid for flex-algo for ISIS.
>>
>> =
>> Section 11.
>>
>> “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2
>> of [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST
>> use legacy advertisements for that link. Flex algorithm application
>> MUST support sending and receiving link attributes with ASLA TLV having 
>> L-bit set.
> 
> 
> I can add the above, although, it's clear from the draft-ietf-isis-te-app 
> that L-bit with legacy advertisement MAY be used for any app.
> 
>>
>> Note that earlier versions of this document did not mandate use of
>> ASLA TLVs and hence may not inter-operate with early implementations that 
>> use legacy advertisements."
> 
> it is not true that "earlier versions of this document" did not mandate ASLA.
> 
> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only supported 
> the include/exclude Admin Groups, clearly stated:
> 
> 
> 9.  Advertisement of Link Attributes for Flex-Algorithm
> 
>  Various link include or exclude rules can be part of the Flex-
>  Algorithm definition.  These rules use Admin Groups (AG) as defined
>  in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
>  as defined in [RFC7308].
> 
>  To advertise a link affinity in a form of the AG or EAG that is used
>  during Flex-Algorithm calculation, an Application Specific Link
>  Attributes 

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

[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] IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (And this one)

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

Hi Acee,

I am not aware of any IPR that has not been disclosed already.

Kind Regards,
G/


From: Acee Lindem (acee) 
Sent: Monday, October 21, 2019 16:43
To: Bocci, Matthew (Nokia - GB) ; Keyur Patel 
; Henderickx, Wim (Nokia - BE/Antwerp) 
; Van De Velde, Gunter (Nokia - BE/Antwerp) 

Cc: lsr@ietf.org; Alvaro Retana 
Subject: IPR Call for New Co-authors of draft-ietf-ospf-mpls-elc-11.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (And this one)

New Author and Contributors,

Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-11?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

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.

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

Re: [Lsr] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (Corrected)

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

Hi Acee,

I am not aware of any IPR that has not been disclosed already.

Kind Regards,
G/

From: Acee Lindem (acee) 
Sent: Monday, October 21, 2019 16:40
To: Bocci, Matthew (Nokia - GB) ; Keyur Patel 
; Henderickx, Wim (Nokia - BE/Antwerp) 
; Van De Velde, Gunter (Nokia - BE/Antwerp) 

Cc: lsr@ietf.org; Alvaro Retana 
Subject: IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - 
"Signaling Entropy Label Capability and Entropy Readable Label-stack Depth 
Using OSPF" (Corrected)

New Author and Contributors,

Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-11?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

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.

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

Re: [Lsr] [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-05.txt

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

This draft has text as agreed and aligned with the MSD sub-type TLV code-point 
allocations as the OSPF/IS-IS ELC/ERLD drafts.

It is short and text is by now stabilized, and ready for WGLC.

G/

-Original Message-
From: Idr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: Tuesday, August 20, 2019 12:48
To: i...@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-05.txt

All,

This is a respin of the ERLD BGP-LS encoding.

It was edited to follow the IGP encodings using a MSD sub-type TLV code-point 
similar as the OSPF/IS-IS ELC/ERLD drafts.

The result is a pretty short remaining text. 

Feedback and suggestions welcome,
G/

-Original Message-
From: Idr  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, August 20, 2019 17:45
To: i-d-annou...@ietf.org
Cc: i...@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title   : Signalling ERLD using BGP-LS
Authors : Gunter Van de Velde
  Wim Henderickx
  Matthew Bocci
  Keyur Patel
Filename: draft-ietf-idr-bgp-ls-segment-routing-rld-05.txt
Pages   : 6
Date: 2019-08-20

Abstract:
   This document defines the attribute encoding to use for BGP-LS to
   expose ERLD "Entropy capable Readable Label Depth" from a node to a
   centralised controller (PCE/SDN).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-05
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-05


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/

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

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

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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

+1 for support.
Seems as a useful extension to have available in OSPF toolbox.

G/

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, February 13, 2019 20:26
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

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

[Lsr] Comments regarding convergence regarding draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding

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

Dear LSR WG,

The LSR chairs informed that attempts to merge drafts 
draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding is exposing 
challenges, and hence asked me as independent unbiased WG contributor to have a 
look at both drafts and provide suggestions on how we may progress to deliver 
the highest quality WG technology deliverable. 

Please find following observations on both documents with my hat of 
"independent unbiased LSR contributor":

Both drafts have clearly written problem space description and in general a 
well written solution space. The problem space is real. Each draft approaches 
the problem space using different accents within the solution space. These 
accents are obvious when the solution-space is discussed in both drafts.

I found the solution space described in "draft-cc-lsr-flooding-reduction" 
centered around restoring flooding topology and making sure that during 
critical changes, flooding is still fast. The solution space provides mechanism 
to make sure that a reduced flooding topology has minimal impact upon 
convergence (it use backup paths, critical paths/node, ...). The compromise to 
achieve fast topology restoration is by introducing a complexity trade-off. For 
example, there are many moving parts from flooding mechanics, to avoid against 
flooding topology split. This raise to me some concern from implementor 
perspective.

The solution space discussed in "draft-li-lsr-dynamic-flooding" uses a generic 
vision based upon solution requirements and seems to focus around protocol 
efficiency/simplicity versus speed of topology convergence. From a 
documentation perspective I found the flow contained by 
"draft-li-lsr-dynamic-flooding" easier to understand. This understanding 
includes packet format descriptions and architectural decisions (for example 
known LSR technology properties/limitations). I found most of the information 
sufficiently well described with minimal complexity. 

In both drafts the distributed algorithm solution seems underspecified and that 
raise implementation concerns to me.

Conclusion:
Coming back to the original request of the LSR chairs asking feedback to 
progress for a quality WG deliverable. I have read both drafts and constructed 
an opinion. Items of interest to me were draft documentation flow, draft 
technological format/content and high level architectural decisions made within 
each proposal. Using those criteria, the balance scales towards 
"draft-li-lsr-dynamic-flooding" because it is using clear solution 
requirements, clear descriptions of encoding and their usage, clear behavioral 
specifications and has considered introducing minimal complexity. This means 
that from review perspective "draft-li-lsr-dynamic-flooding" seems best 
candidate to adopt with most potential for high quality WG deliverable. In 
addition, we could assign a shepherd to work within the WG. If needed I am 
happy to help shepherding the WG deliverable.

This work is important for industry. The solution must work and be causing less 
issues as the problem we are trying to fix. 
We need to progress the work on flooding reduction. We need to select the most 
optimal/pragmatic solution.
 
Obviously, additional reviews from WG contributors will help LSR WG to define 
and build the highest quality WG deliverable. 

Kind Regards,
Gunter Van de Velde

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

[Lsr] Comments regarding convergence regarding draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding

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

[with corrected copy/paste in cc]

Dear LSR WG,

The LSR chairs informed that attempts to merge drafts 
draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding is exposing 
challenges, and hence asked me as independent unbiased WG contributor to have a 
look at both drafts and provide suggestions on how we may progress to deliver 
the highest quality WG technology deliverable. 

Please find following observations on both documents with my hat of 
"independent unbiased LSR contributor":

Both drafts have clearly written problem space description and in general a 
well written solution space. The problem space is real. Each draft approaches 
the problem space using different accents within the solution space. These 
accents are obvious when the solution-space is discussed in both drafts.

I found the solution space described in "draft-cc-lsr-flooding-reduction" 
centered around restoring flooding topology and making sure that during 
critical changes, flooding is still fast. The solution space provides mechanism 
to make sure that a reduced flooding topology has minimal impact upon 
convergence (it use backup paths, critical paths/node, ...). The compromise to 
achieve fast topology restoration is by introducing a complexity trade-off. For 
example, there are many moving parts from flooding mechanics, to avoid against 
flooding topology split. This raise to me some concern from implementor 
perspective.

The solution space discussed in "draft-li-lsr-dynamic-flooding" uses a generic 
vision based upon solution requirements and seems to focus around protocol 
efficiency/simplicity versus speed of topology convergence. From a 
documentation perspective I found the flow contained by 
"draft-li-lsr-dynamic-flooding" easier to understand. This understanding 
includes packet format descriptions and architectural decisions (for example 
known LSR technology properties/limitations). I found most of the information 
sufficiently well described with minimal complexity. 

In both drafts the distributed algorithm solution seems underspecified and that 
raise implementation concerns to me.

Conclusion:
Coming back to the original request of the LSR chairs asking feedback to 
progress for a quality WG deliverable. I have read both drafts and constructed 
an opinion. Items of interest to me were draft documentation flow, draft 
technological format/content and high level architectural decisions made within 
each proposal. Using those criteria, the balance scales towards 
"draft-li-lsr-dynamic-flooding" because it is using clear solution 
requirements, clear descriptions of encoding and their usage, clear behavioral 
specifications and has considered introducing minimal complexity. This means 
that from review perspective "draft-li-lsr-dynamic-flooding" seems best 
candidate to adopt with most potential for high quality WG deliverable. In 
addition, we could assign a shepherd to work within the WG. If needed I am 
happy to help shepherding the WG deliverable.

This work is important for industry. The solution must work and be causing less 
issues as the problem we are trying to fix. 
We need to progress the work on flooding reduction. We need to select the most 
optimal/pragmatic solution.
 
Obviously, additional reviews from WG contributors will help LSR WG to define 
and build the highest quality WG deliverable. 

Kind Regards,
Gunter Van de Velde

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

Re: [Lsr] A new proposal on how to do Sparse Link-State Flooding in Dense Topologies

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

Hi Eric,

Indeed, my first impression is that you are indeed correct. Thanks from 
pointing this out. It seems to me a valid observation.
One of the first worries we had while crafting the draft is the potential of 
ending up with a fragmented control plane environment.

A first impression is that adding restrictions upon anchor placement when +1 
flooding anchor is used (for example they must be 
directly connected (or at least not further away as "1-hop")) could resolve 
this. It would be less gracious, but the simplicity of the 
algorithm may compensate for it. 

Thanks again for sharing this observation.

G/


-Original Message-
From: Eric Rosen  
Sent: Monday, November 19, 2018 16:52
To: Henk Smit ; lsr@ietf.org
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Subject: Re: [Lsr] A new proposal on how to do Sparse Link-State Flooding in 
Dense Topologies

Let's test out this simple algorithm on a simple topology:

A--B--C--D--E--F

where B and E are both configured as potential anchor nodes.

To make it even simpler, suppose we set this up in the lab, and power up all 
six routers at the same time.

Now there may be some moment at which:

- A and C have seen LSPs from A, B, C, and D, but have have not seen the LSP 
from E.

- D and F have seen the LSPs from C, D, E, and F, but have not seen the LSP 
from B.

So A, B, and C will choose B as the anchor, enabling flooding on AB and BC.

Also, D, E, and F will choose D as the anchor, enabling flooding on DE and EF.

C will request flooding to be disabled on CD, since it leads away from B.

D will request flooding to be disabled on DC, since it leads away from E.

So there is no flooding on CD/DC.

Now A, B, and C will never get an LSP from E, while D, E, and F will never get 
an LSP from B.

Since CD/DC was never down, there is no reason to do a database exchange over 
it.

It seems like the network is permanently broken, as the flooding topology is 
partitioned by CD/DC.

Did I miss something?



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

Re: [Lsr] Teasing us with secrets

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

> What I am very concerned about is that we are focused on the wrong problem. 
> We don't have a problem flooding a large number of LSPs on a single interface.

The fact that there is undocumented knowledge that completely contradicts 
established standards that is necessary for scalable operations implies that 
there is indeed a problem.

GV> I agree with Tony. Maybe the ISISoTCP draft is addressing the wrong 
problem, but the WG should either explain or should not use undocumented 
knowledge as argument. Undocumented is undocumented. Undocumented information 
is not a normative position to say "only the happy few know, and we are not 
explaining". That seems not a nice and friendly and appropriate position to 
defend. The authors of "draft-hsmit-lsr-isis-flooding-over-tcp-00"  tried to 
deliver an educated objective description and explanation why there is an issue 
with the current standard behavior, and sofar I did not receive any indication 
at all, what is wrong or incorrect with the documented issues in the 
draft-hsmit-lsr-isis-flooding-over-tcp-00 draft. 

G/

-Original Message-
From: Lsr  On Behalf Of tony...@tony.li
Sent: Thursday, November 8, 2018 04:40
To: Les Ginsberg 
Cc: lsr@ietf.org; Henk Smit 
Subject: Re: [Lsr] Teasing us with secrets


Les,

> I am not "teasing".
> I also don't think this is much of a secret.
> 
> I am pretty sure experienced implementers know what I am talking about.
> (BTW, I include you in that group. :-) )


Ongoing undocumented knowledge is wholly irrelevant when writing standards.  
There’s simply nothing to reference and thus a tease.

It’s true that there is no obligation to document this knowledge, but at the 
same time, that knowledge cannot be used to pre-empt alternative solutions.


> What I am very concerned about is that we are focused on the wrong problem. 
> We don't have a problem flooding a large number of LSPs on a single interface.

The fact that there is undocumented knowledge that completely contradicts 
established standards that is necessary for scalable operations implies that 
there is indeed a problem.

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] Signalling ERLD (ISIS, OSPF and BGP-LS)

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

Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic 
motivation.

The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is 
available, then ELC can be implicitly assumed. No pragmatic reason to signal 
separately, as it just make things more complex then should be. 

>From a holistic perspective having something similar, yet different, in both 
>IGP and BGP-LS encoding 
seems to make little sense and only bring confusion (router/controller 
implementers and network operators). 

The ways to address this in IGP and BGP-LS going forward:
1) do nothing and leave all as it is (it has potential to create massive 
confusion) 
2) only signal ERLD TLV in IGP and BGP
3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of 
ELC TLV compared to option (2)) 
4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more 
complex as option (2))

I believe that option (2) is the best option:
* it bring the needed readable label depth value to operators 
* most simple solution for implementers (routers and controller)  
* easy to understand with no confusion
* is compliant with draft-ietf-mpls-spring-entropy-label-10

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 08:05
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

The difference in IGP signalling seems to be because the ELC is a capability 
which is advertised differently than ERLD which is a limit. Are you saying that 
ELC does not have value by itself without the ERLD?

IMHO it makes sense to retain ELC as capability of the router (as specified in 
the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. 
This way we have the flexibility of signalling ERLD both per node and per 
ingress link/LC level.

Thanks,
Ketan

-Original Message-
From: Idr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: 12 June 2018 19:28
To: i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is 
need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is 
signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that 
should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon 
(https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10)
* What are the plans to request IANA code points for these drafts?
* (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK 
ERLD is not of any value at all, is that a correct assumption?)

G/


-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 12, 2018 15:25
To: i-d-annou...@ietf.org
Cc: i...@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title   : Signalling ERLD using BGP-LS
Authors : Gunter Van de Velde
  Wim Henderickx
  Matthew Bocci
  Keyur Patel
Filename: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt
Pages   : 6
Date: 2018-06-12

Abstract:
   This document defines the attribute encoding to use for BGP-LS to
   expose ERLD "Entropy capable Readable Label Depth" from a node to a
   centralised controller (PCE/SDN).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-02


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/

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

___

[Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)

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

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is 
need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth)
ISIS/OSPF is signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that 
should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon 
(https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10)
* What are the plans to request IANA code points for these drafts?
* (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK 
ERLD is not of any value at all, is that a correct assumption?)

G/


-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 12, 2018 15:25
To: i-d-annou...@ietf.org
Cc: i...@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title   : Signalling ERLD using BGP-LS
Authors : Gunter Van de Velde
  Wim Henderickx
  Matthew Bocci
  Keyur Patel
Filename: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt
Pages   : 6
Date: 2018-06-12

Abstract:
   This document defines the attribute encoding to use for BGP-LS to
   expose ERLD "Entropy capable Readable Label Depth" from a node to a
   centralised controller (PCE/SDN).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-02


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/

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

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

[Lsr] LSVR Interim meeting details [Webex & agenda details included]

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

Hi All,

What:
  LSVR WG Interim Meeting

When:
  1) Date: Friday 8 June 2018
  2) Time: 07:30am PDT (=4:30pm CET) 
  3) Length: 90 minutes

Provisional agenda:

  1) Admin, agenda bashing and WG Status Update (20m - chairs)
  2) Shortest Path Routing Extensions for BGP Protocol (30m - Keyur)
  3) Usage and Applicability of Link State Vector Routing in Data Centers (20m 
- Acee)
  4) Discussion: Next steps regarding Neighbor and Liveliness detection 
(LLDP/LSoE/ECP) (20m - Chairs/All)

Meeting details:

  1) Meeting Link:
  https://ietf.webex.com/ietf/j.php?MTID=mc6db88664131504ccc9cb69278e100ec
  2) Meeting number:
  643 222 923
  3) Meeting password:
  jKR2graY
  4) Audio connection:
  1-650-479-3208 Call-in toll number (US/Canada)
  Access code: 643 222 923

Kind Regards,
Gunter & Victor
LSVR co-chairs

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Van De Velde, Gunter 
(Nokia - BE/Antwerp)
Sent: Friday, June 1, 2018 09:17
To: i...@ietf.org; l...@ietf.org; lsr@ietf.org
Cc: draft-ietf-lsvr-bgp-...@ietf.org
Subject: Re: [Lsr] [Lsvr] I-D Action: draft-ietf-lsvr-bgp-spf-01.txt

Hi All,

Friday 8 June LSVR WG will have a 90 minute interim meeting to discuss the 
updates/feedback/next-steps regarding drafts:

https://www.ietf.org/id/draft-ietf-lsvr-bgp-spf-01.txt
and
https://www.ietf.org/id/draft-keyupate-lsvr-applicability-01.txt

The interim is scheduled for Friday 8 June, 4:30pm CET (= 7:30am PDT), using 
Webex conference tool.

Agenda, slides and other details will be shared on the datatracker interim LSVR 
page:
https://datatracker.ietf.org/meeting/interim-2018-lsvr-01/session/lsvr

Webex details to be distributed soon in the LSVR WG email list

Brgds,
G/

-Original Message-
From: Lsvr [mailto:lsvr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Friday, June 1, 2018 01:40
To: i-d-annou...@ietf.org
Cc: l...@ietf.org
Subject: [Lsvr] I-D Action: draft-ietf-lsvr-bgp-spf-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Vector Routing WG of the IETF.

Title   : Shortest Path Routing Extensions for BGP Protocol
Authors : Keyur Patel
  Acee Lindem
  Shawn Zandi
  Wim Henderickx
Filename: draft-ietf-lsvr-bgp-spf-01.txt
Pages   : 16
Date: 2018-05-31

Abstract:
   Many Massively Scaled Data Centers (MSDCs) have converged on
   simplified layer 3 routing.  Furthermore, requirements for
   operational simplicity have lead many of these MSDCs to converge on
   BGP as their single routing protocol for both their fabric routing
   and their Data Center Interconnect (DCI) routing.  This document
   describes a solution which leverages BGP Link-State distribution and
   the Shortest Path First (SPF) algorithm similar to Internal Gateway
   Protocols (IGPs) such as OSPF.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsvr-bgp-spf-01
https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsvr-bgp-spf-01


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/

___
Lsvr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsvr

___
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] FW: Requested: Volunteers to review draft-keyupate-lsvr-bgp-spf-00

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

Due to the adjacent nature of LSVR regarding LSR WG technology, the experience 
and feedback from the LSR WG is appreciated.

Please let LSVR WG co-chairs know if you see opportunity to provide help 
regarding review/comments on draft draft-keyupate-lsvr-bgp-spf-00

Kind Regards,

Gunter & Victor
LSVR WG Co-chairs

-Original Message-
From: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Sent: Friday, March 30, 2018 09:16
To: l...@ietf.org
Subject: Requested: Volunteers to review draft-keyupate-lsvr-bgp-spf-00 

Hi All,

As mentioned during the LSVR WG session during IETF101, we will soon be 
launching a LSVR WG Adoption call regarding
draft-keyupate-lsvr-bgp-spf-00

It would be beneficial to have a few volunteers (maybe even named volunteers?) 
to help the chairs understanding regarding the quality of this document, with 
intend to expedite technological discussion and document progress.

Please inform LSVR chairs if you see opportunity to provide feedback during the 
next 2.5 weeks to help with review comments.

Kind Regards,
Gunter & Victor

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