Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label

[Hannes Gredler]

Hi John,

Section 2.1 defines also the bits to be used in the flags field:

where:

[ ... ]
V-Flag:
Value Flag. If set, then the Prefix-SID carries a value (instead of an index). 
By default, the flag is UNSET.
L-Flag:
Local Flag. If set, then the value/index carried by the Prefix-SID has local 
significance. By default, the flag is UNSET.

[ ... ]

When the Prefix-SID is an index (and the V-Flag is not set), the value is used 
to determine the actual label value inside the set of all advertised label 
ranges of a given router. This allows a receiving router to construct the 
forwarding state to a particular destination router.

--

We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and I 
am not aware
of any questions from implementators around ambiguity.

IMO there is clear enough language to describe proper encoding of the 
prefix-SID subTLV and
I am not sure why an "erratum" is required.

/hannes

On Wed, Dec 06, 2023 at 09:13:15PM +, John Scudder wrote:
| Hi Authors and Contributors who "should be considered as coauthors”,
| 
| Your RFC defines the SID/Index/Label field of the Prefix Segment Identifier 
(Prefix-SID) Sub-TLV, in Section 2.1, as:
| 
|   SID/Index/Label as defined in Section 2.1.1.1.
| 
| But when I look at Section 2.1.1.1 I see that it defines "V-Flag and L-Flag”, 
not SID/Index/Label at all. It relates to the interpretation of 
SID/Index/Label, yes, but it doesn’t define the field.
| 
| It seems as though an erratum is needed to provide a useful definition. I 
don’t have text to suggest. Can one of you suggest text, and either raise the 
erratum yourself, or if you send text, I can raise it? Alternatively, if you 
can help me understand how section 2.1.1.1 actually does define this field, I'm 
all ears.
| 
| Thanks,
| 
| --John
| ___
| 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Hannes Gredler]

+1.

Changing the semantics of a 20 year+ deployed protocol is most always a bad idea
and for sure will lead into unanticipated side-effects.

FWIW - I do no dispute the usefulness of an "unreachable prefix",
but would strongly advocate for a dedicated protocol extension.

/hannes

On Wed, Aug 23, 2023 at 02:09:46PM -0700, Tony Li wrote:
| 
| I object. This solution is a poor way of addressing the issues.  My reasons 
have been discussed to death already.
| 
| Tony
| 
| 
| > On Aug 23, 2023, at 1:07 PM, Acee Lindem  wrote:
| > 
| > LSR Working Group,
| > 
| > This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
| > Please indicate your support or objection on this list prior to September 
7th, 2023. 
| > 
| > Thanks,
| > Acee
| > ___
| > Lsr mailing list
| > Lsr@ietf.org
| > https://www.ietf.org/mailman/listinfo/lsr
| 
| ___
| Lsr mailing list
| Lsr@ietf.org
| https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] Working Group Last Call for "IS-IS Fast Flooding" - draft-ietf-lsr-isis-fast-flooding-04

[Hannes Gredler]

support

Sent from my iPhone

> On 20.07.2023, at 02:12, Jordan Head  wrote:
> 
>  Support
> 
> Jordan
> 
>> On Jul 19, 2023, at 7:40 PM, Tony Li  wrote:
>> 
>> 
>> Support
>> 
>> T
>> 
>> 
 On Jul 19, 2023, at 4:06 PM, Acee Lindem  wrote:
>>> 
>>> This begins three week LSR Working Group last call for the “IS-IS Fast 
>>> Flooding”. Please express your support or objection prior to Friday, August 
>>> 11th, 2023. The longer WG last call is to account for the IETF being next 
>>> week. 
>>> 
>>> Thanks,
>>> Acee
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] [IANA #1239131] expert review for draft-ietf-lsr-isis-rfc5316bis (isis-tlv-codepoints)

[Hannes Gredler]

Hi Sabrina,

Approved from my end.

Thanks,

/hannes

> On 01.09.2022, at 23:58, Christian Hopps  wrote:
> 
> 
> "Sabrina Tanamal via RT"  writes:
> 
>> Chris and Hannes (cc: lsr WG),
> 
> 
> Reviewed new addition, looks OK.
> 
> Thanks,
> Chris.
> 
>> 
>> As the designated experts for the Sub-TLVs for TLVs Advertising Neighbor 
>> Information registry, can you review the proposed registration in 
>> draft-ietf-lsr-isis-rfc5316bis for us? Please see
>> 
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc5316bis
>> 
>> If this is OK, when the IESG approves the document for publication, we'll 
>> make the registration at
>> 
>> https://www.iana.org/assignments/isis-tlv-codepoints
>> 
>> Les Ginsberg is also an expert for this registry, but he's one of the 
>> authors of this document.
>> 
>> If you're available, the due date is September 14th.
>> 
>> thanks,
>> 
>> Sabrina Tanamal
>> Lead IANA Services Specialist
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Hannes Gredler]

+1

Sent from my iPhone

> On 27.07.2022, at 23:39, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 
> (Preamble: All of what I am going to say I have said many times before – on 
> the list – off the list – in private conversations – in WG meetings…
> I don’t say this to start a discussion with the WG authors – it seems clear 
> that we don’t agree and have no path to agreement.
> My purpose in saying this is to respond to the ongoing existence of this 
> draft and offering my opinion as to what action the WG should take.)
>  
> The mechanism defined in this draft is broken. Not only is it not backwards 
> compatible – the PUA advertisements will be misinterpreted to mean the exact 
> opposite of what is intended i.e., the intent is to signal that a prefix is 
> unreachable, but you do so by using an advertisement which legacy nodes MUST 
> interpret as meaning reachable. This is simply broken and should not be done.
>  
> The authors deserve credit for bringing the attention of the WG to the 
> problem space – but the solution offered is not deployable. Given the long 
> period of time during which this draft has been published and the many times 
> it has been presented/discussed in the WG I think it is now time to say thank 
> you to the authors for their work, but the WG is not interested in adopting 
> this draft.
>  
>Les
>  
>  
> From: Lsr  On Behalf Of Ketan Talaulikar
> Sent: Wednesday, July 27, 2022 1:36 AM
> To: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org
> Cc: lsr 
> Subject: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
>  
> Hello Authors,
>  
> I am sharing some comments on the latest version of this document since we 
> seem to have a packed agenda in LSR this time.
>  
> 1) I notice that in the latest update of the draft, there is a big change to 
> start using LSInfinity for indicating prefix unreachability (similar to 
> draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a 
> degree of convergence between the two drafts.
>  
> 2) However, I then question the motivation of the authors to continue with 
> the bad design of overloading Prefix Originator and the added capability 
> stuff on top. I don't wish to repeat why that design was an absolute NO-GO 
> for me and I am glad to see the authors acknowledge the problem with 
> misrouting by implementations not supporting this specification. So I don't 
> see the point of still retaining all that. 
>  
> Thanks,
> Ketan
>  
> ___
> 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] IGP Monitoring Protocol

[Hannes Gredler]

Hi Robert,

When designing BGP-LS we had to make a fundamental choice for expressing an 
link-state graph.
the two models under consideration:

1) encapsulating raw IGP LS PDUs into some NLRI
2) transcoding all elements of a graph (nodes, links, prefixes, node attributes 
and link attributes)
   into some NLRI

We did see some value for getting visibility of serialized LS PDUs (proposal 
1), but then decided
against it as the primary use-case has been to be friendly to controllers where 
controller developers
told us they do not want to to implement each and every protocol specific IGP 
extension, but rather be comfortable
with a "protocol neutral" representation of a LS graph (proposal 2).
So here we are - if a certain feature is relevant to a controller, then you 
need to specify a
BGP-LS transcoding scheme / TLV - no way around that if you want to be friendly 
to controller developers.
As the IMP proposal stands today there is not much additional value compared to 
the local-LSDB that BGP-LS provides already.

However, for debugging IGPs there is certainly some value in monitoring the 
flooding subsystem.
Now if you want to however monitor what's going on at the flooding level of 
your IGP then there is
a tad of information missing in the current proposal.

For further illustration let me pull-up the BMP analogy, where there is a clear 
per-RIB orientation:
e.g. from which peer a NLRI has been received from ?
 what NLRI has been sent to particular peer ?
 per-peer stats, global stats ?

That per-adj related information is IMO missing for IMP to be useful.
additional data of interest -> where (interface) and when a LS PDU has been 
received (redundant copies ?), retransmisison stats,
differentiate between LSDB-in / LSDB-out, LSDB-self-originated ?

I am sure that bruno and his team have way more ideas for data that they would 
be interested in ;-)

/hannes

On Fri, Jul 08, 2022 at 09:20:04PM +0200, Robert Raszuk wrote:
|Dear LSR WG,
|Based on ongoing discussion in respect to the future of BGP-LS I
|committed myself to put together an alternate proposal. 
|The main goal is not to just publish a -00 version of the draft using
|different encapsulation. The goal is to make a useful tool which can help
|to export link state information from network elements as well as assist
|in network observability. 
|The IGP Monitoring Protocol (IMP) draft has been posted and should be
|available at:
|https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/
|One of the key points I wanted to accomplish was full backwards
|compatibility with TLVs defined for BGP-LS. In parallel other formats
|(optional) are also supported. 
|The PUB-SUB nature or FILTERING capabilities are in the spec however as
|noted in the deployment section there is no expectation that this should
|be supported directly on routers. Concept of Producer's Proxies has been
|introduced to support this added functionality as well as provide fan-out
|(analogy to BGP route reflectors). 
|I encourage everyone interested to take a look and provide comments. At
|this point this document is nothing more than my individual submission.
|Offline I have had few conversations with both operators and vendors
|expressing some level of interest in this work. How we proceed further (if
|at all :) depends on WG feedback. 
|Kind regards,
|Robert.
|PS, I do believe this work belongs in LSR WG pretty squerly. 

| ___
| 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] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Hannes Gredler]

Hi Tony, et al,

minor nit:

---
   As an example, consider the Extended IS Reachability TLV (type 22).
   A neighbor in this TLV is specified by:

   *  7 octets of system ID and pseudonode number
   *  3 octets of default metric

   This acts as the key for this entry.  The key is followed by up to
   244 octets of sub-TLV information.
---

I believe that in most implementations the key in the LSDB is the 7 octets of 
system ID and pseudonode number
and does not include the metric (it's really an attribute to the key), whereas 
the current wording might
wrongly imply that the key is {sysid, PSN and metric}.

thanks,

/hannes

|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" , "Chris Bowers"
|  , "Les Ginsberg" , "Parag
|  Kaneriya" , "Shraddha Hegde"
|  , "Tony Li" , "Tony Przygienda"
|  
| 
|   
| 
|  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
| 
| 
| 
|  
_
| 
|  Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
|  pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
|  a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
|  Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.
| 
|  This message and its attachments may contain confidential or privileged 
information that may be protected by law;
|  they should not be distributed, used or copied without authorisation.
|  If you have received this email in error, please notify the sender and 
delete this message and its attachments.
|  As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
|  Thank you.

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

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

Re: [Lsr] BGP vs PUA/PULSE

[Hannes Gredler]

hi peter,

Just curious: Do you have an idea how to make short-lived LSPs compatible with 
the problem stated in
https://datatracker.ietf.org/doc/html/rfc7987

Would like to hear your thoughts on that.

thanks,

/hannes

On Tue, Nov 30, 2021 at 01:15:04PM +0100, Peter Psenak wrote:
| Hi Robert,
| 
| On 30/11/2021 12:40, Robert Raszuk wrote:
| > Hey Peter,
| > 
| >  > #1 - I am not ok with the ephemeral nature of the advertisements. (I
| >  > proposed an alternative).
| > 
| > LSPs have their age today. One can generate LSP with the lifetime of 1
| > min. Protocol already allows that.
| > 
| > 
| > That's a pretty clever comparison indeed. I had a feeling it will come
| > up here and here you go :)
| > 
| > But I am afraid this is not comparing apple to apples.
| > 
| > In LSPs or LSA flooding you have a bunch of mechanisms to make sure the
| > information stays fresh
| > and does not time out. And the default refresh in ISIS if I recall was
| > something like 15 minutes ?
| 
| yes, default refresh is 900 for the default lifetime of 1200 sec. Most
| people change both to much larger values.
| 
| If I send the LSP with the lifetime of 1 min, there will never be any
| refresh of it. It will last 1 min and then will be purged and removed from
| the database. The only difference with the Pulse LSP is that it is not
| purged to avoid additional flooding.
| 
| 
| > 
| > Today in all MPLS networks host routes from all areas are "spread"
| > everywhere including all P and PE routers, that's how LS protocols
| > distribute data, we have no other way to do that in LS IGPs.
| > 
| > 
| > Can't you run OSPF over GRE ? For ISIS Henk had proposal not so long ago
| > to run it over TCP too.
| > 
https://datatracker.ietf.org/doc/html/draft-hsmit-lsr-isis-flooding-over-tcp-00
| 
| you can run anything over GRE, including IGPs, and you don't need TCP
| transport for that. I don't see the relevance here. Are you suggesting to
| create GRE tunnels to all PEs that need the pulses? Nah, that would be an
| ugly requirement.
| 
| thanks,
| Peter
| 
| 
| > 
| > Seems like a perfect fit !
| > 
| > Thx,
| > R.
| 

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

Re: [Lsr] BGP vs PUA/PULSE

[Hannes Gredler]

hi les,

please see inline.

On Mon, Nov 29, 2021 at 10:39:17PM +, Les Ginsberg (ginsberg) wrote:
|Hannes -
| 
| 
| 
|Thanx for bringing a new voice into the discussion.
| 
|Please see inline.
| 
| 
| 
|> -Original Message-
| 
|> From: Hannes Gredler 
| 
|> Sent: Monday, November 29, 2021 1:27 AM
| 
|> To: Aijun Wang 
| 
|> Cc: 'Robert Raszuk' ; 'lsr' ; Les
|Ginsberg
| 
|> (ginsberg) ; 'Tony Li' ; 'Shraddha
| 
|> Hegde' ; Peter Psenak (ppsenak)
| 
|> 
| 
|> Subject: Re: [Lsr] BGP vs PUA/PULSE
| 
|>
| 
|> On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote:
| 
|>
| 
|> [ ... ]
| 
|>
| 
|> |Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the
| 
|> different
| 
|> |is how to propagate such “DOWN” information. Considering we have
| 
|> observed
| 
|> |that all P/PE router in other areas may be interested such
|information,
| 
|> |your proposal will require every P/PE router run BGP-LS, which is
|not the
| 
|> |aimed deploy scenarios for BGP-LS.
| 
|>
| 
|> HG> BGP-LS has been conceived to solve the very problem of providing
| 
|> visibility of other
| 
|> area's link state. I fail to see what is out of scope here.
| 
|>
| 
|[LES:] BGP-LS only advertises what the IGPs themselves advertise.

HG> That is an implementation choice; the protocol allows multiple sources of 
information.
https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#protocol-ids
And even standalone implementations are fine as the LSVR WG suggests.

|In this case, both IGP proposals involve ephemeral advertisements - so
|even if we were to define BGP-LS support for these new advertisements -
|they wouldn't persist long enough to be reflected in BGP-LS.

HG> you could model the liveliness tracker as a "source protocol" and advertise 
the state of your endpoint.

|So, I really don’t know why we are discussing BGP-LS in the context of
|this thread.

HG> because some people think it's a bad a idea to put this corner-case app in 
the very core of our networks.

|(This seems to be one example of what Acee correctly identified as this
|discussion going "off track".)

HG> please do not derail the discussion. It is well within the mandate of LSR 
to discuss solution space and have a healthy discussion
about the scalingaspects of a proposal. If the WG has concerns on the scaling 
properties and brings up alternatives to make a given
use-case work that is IMO fine and we may just use some airtime for that. After 
all it's link-state routing, right ?

| 
| 
| 
|> |Then, if IGP has such capabilities, why bother BGP? What is the
|benefit?
| 
|>
| 
|> HG> simply put: seperation of concerns. Agreed consensus is to mostly
|use
| 
|> the
| 
|> IGP for topology discovery and put the bulk of carrying reachability
| 
|> information
| 
|> into BGP which gives us:
| 
|>
| 
|[LES:] I am not convinced either side can claim "consensus" in this
|discussion. That is a work in progress. 

HG> by consensus i meant that the BGP/IGP split is common practise of building 
large scale networks.

|However, when you say IGPs are (exclusively?) for topology discovery - it
|seems to suggest that IGP shouldn’t be advertising prefix reachability at
|all. Hopefully, that is not what you intend.

HG> did not say that. of course we need minimal IP reachability for 
bootstrapping the iBGP transport mesh.
but we certainly do not use the IGP for carrying bulk routes at (Internet) 
scale.
 
|One of the points that still baffles me is the assertion of an
|architectural violation in the IGP proposals.
| 

HG> did not say that.

| 
|It is OK for IGPs to advertise all prefixes covered by a summary (i.e., do
|not summarize).
| 
|It is OK for IGPs to advertise multiple summaries (e.g., multiple /24s
|instead of a single /16).
| 
|It is even OK for IGPs to advertise some prefixes covered by a summary
|along with the summary (don’t know if any implementations do this - but
|they could).
| 
|None of this is an "architectural violation".
| 

HG> Again - Don't think its an architectual violation - I just think in it's 
current state
it has a lot of havoc potential under load.
 
|But advertising a summary and signaling the loss of reachability to a
|specific prefix covered by the summary is seen by some as an architectural
|violation.
| 
|Sorry, I still don't understand this argument.
|
| 
| 
|You can not like the approach. You can be concerned about scaling
|properties (more on that below). You can question the effectiveness of
|ephemeral advertisemen

Re: [Lsr] BGP vs PUA/PULSE

[Hannes Gredler]

hi aijun,

On Mon, Nov 29, 2021 at 07:16:18PM +0800, Aijun Wang wrote:
| Hi, Hannes:
| 
| -Original Message-
| From: Hannes Gredler  
| Sent: Monday, November 29, 2021 5:27 PM
| To: Aijun Wang 
| Cc: 'Robert Raszuk' ; 'lsr' ; 'Les Ginsberg 
(ginsberg)' ; 'Tony Li' ; 'Shraddha Hegde' 
; 'Peter Psenak' 
| Subject: Re: [Lsr] BGP vs PUA/PULSE
| 
| On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote:
| 
| [ ... ]
| 
| |Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the different
| |is how to propagate such “DOWN” information. Considering we have observed
| |that all P/PE router in other areas may be interested such information,
| |your proposal will require every P/PE router run BGP-LS, which is not the
| |aimed deploy scenarios for BGP-LS.
|  
| HG> BGP-LS has been conceived to solve the very problem of providing 
| HG> visibility of other
| area's link state. I fail to see what is out of scope here.
| [WAJ] Yes. But it is not for the nodes within IGP itself. It's main aim is to 
feed the underlay topology information to the controller.


HG> BGP-LS has been used now beyond 3rd party controllers. I do also see you as 
co-author of some drafts in LSVR
Note that a similar protocol machinery like used in LSVR can be made to 
work for your use case here.

| |Then, if IGP has such capabilities, why bother BGP? What is the benefit?
| 
| HG> simply put: seperation of concerns. Agreed consensus is to mostly 
| HG> use the
| IGP for topology discovery and put the bulk of carrying reachability 
information into BGP which gives us:
| 
| 1) flow-control capabilities (=by virtue of TCP) and
| 2) furthermore operators can scale and isolate the distribution vehicle for a 
given AFI/SAFI service
|using a dedicated RR infrastructure which does not mess with your bread 
and butter service
|infra.
| 
| IMO it is not a good idea to put (negative) reachability information back 
into the IGP as you would loose this "seperation of concerns" aspect and 
potentially de-stabilize your topology discovery tool and hence *all* your 
bread-and-butter services.
| [WAJ] Yes. We are seeking the solution to the potential use of such 
unreachable information. Current BGP solutions has not convinced me until now.

perhaps you start elaborating what *exactly* you find not convincing of the 
proposed IGP/BGP split.

thanks,

/hannes

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

Re: [Lsr] BGP vs PUA/PULSE

[Hannes Gredler]

On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote:

[ ... ]

|Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the different
|is how to propagate such “DOWN” information. Considering we have observed
|that all P/PE router in other areas may be interested such information,
|your proposal will require every P/PE router run BGP-LS, which is not the
|aimed deploy scenarios for BGP-LS.
 
HG> BGP-LS has been conceived to solve the very problem of providing visibility 
of other
area's link state. I fail to see what is out of scope here.

|Then, if IGP has such capabilities, why bother BGP? What is the benefit?

HG> simply put: seperation of concerns. Agreed consensus is to mostly use the
IGP for topology discovery and put the bulk of carrying reachability information
into BGP which gives us:

1) flow-control capabilities (=by virtue of TCP) and
2) furthermore operators can scale and isolate the distribution vehicle for a 
given AFI/SAFI service
   using a dedicated RR infrastructure which does not mess with your bread and 
butter service
   infra.

IMO it is not a good idea to put (negative) reachability information back into 
the IGP as you
would loose this "seperation of concerns" aspect and potentially de-stabilize 
your topology discovery
tool and hence *all* your bread-and-butter services.

HTH,

/hannes

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

Re: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[Hannes Gredler]

support;

On Mon, Nov 22, 2021 at 02:06:37PM +, Acee Lindem (acee) wrote:
|We indicated the intent to adopt of
|draft-decraeneginsberg-lsr-isis-fast-flooding-00 as an LSR WG document at
|the IETF 112 LSR WG meeting.
| 
|We are now confirming WG consensus on this action. Please indicate your
|support or objection on this list by 12:00 AM UTC on December 7^th, 2021.
| 
| 
| 
|Another question that came to light is whether the document should be
|standards track or experimental. If you have an opinion on this matter,
|please chime in along with your arguments for one track or the other. We
|probably won’t make a final decision on this now but let’s get the
|discussion started.
| 
| 
| 
|Here is a link for your convenience:
| 
| 
| 
|
https://datatracker.ietf.org/doc/draft-decraeneginsberg-lsr-isis-fast-flooding/
| 
| 
| 
|Thanks,
|Acee

| ___
| 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] draft-tgraf-ipfix-mpls-sr-label-type

[Hannes Gredler]

Thomas,

I have one comment/suggestion to Paragraph 4 (IANA Considerations).

Please add also a code point for BGP Prefix-SID - it’s quite popular in DC 
deployments.
https://tools.ietf.org/html/rfc8669 

thanks,

/hannes

> On 28.07.2020, at 10:11, thomas.g...@swisscom.com wrote:
> 
> Dear lsr,
>  
> I presented the following draft
>  
> Export of MPLS Segment Routing Label Type Information in IP Flow Information 
> Export (IPFIX)
> https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 
> 
>  
> at the spring working group at IETF 108 yesterday
> https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf
>  
> 
>  
> and today at OPSAWG where I call for adoption.
>  
> This draft adds additional segment routing code points for in the IANA IPFIX 
> registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to gain 
> further insights into the MPLS-SR forwarding-plane.
>  
> I have been asked to not only gather feedback from spring and opsawg but also 
> from lsr and mpls working groups since these code points are related to link 
> state routing protocols and mpls data plane.
>  
> I am looking forward to your feedback and input.
>  
> Best Wishes
> Thomas Graf
> ___
> 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] "IGP Extensions for Segment Routing Service Segment" -draft-lz-lsr-igp-sr-service-segments-02

[Hannes Gredler]

Yao,

BGP-LS was designed to solve also the distribution of link-state information 
between BGP speakers (see Figure 1 from RFC 7752 below).
Just ask yourself: why would one want to use a point to multipoint state 
replication protocol as complex as BGP for *just* client server alike 
replication ?

We wanted from day-1 to leverage the graph independent replication abilities of 
BGP - so doing inter BGP-LS graphs is a legit use-case.

HTH,

/hannes

--- 


   The collection of link-state and TE information and its distribution
   to consumers is shown in the following figure.

   +---+
   | Consumer  |
   +---+
 ^
 |
   +---+
   |BGP|   +---+
   |  Speaker  |   | Consumer  |
   +---+   +---+
 ^   ^   ^   ^
 |   |   |   |
 +---+   |   +---+   |
 |   |   |   |
   +---+   +---+ +---+
   |BGP|   |BGP| |BGP|
   |  Speaker  |   |  Speaker  |. . .|  Speaker  |
   +---+   +---+ +---+
 ^   ^ ^
 |   | |
IGP IGP   IGP

   Figure 1: Collection of Link-State and TE Information

---

> On 29.07.2020, at 03:57, liu.ya...@zte.com.cn wrote:
> 
> Hi Acee,
> 
> Thanks for reading the draft.
> 
> Yes, the main purpose of this draft is to carry the segment segment 
> information via IGP so only one node per AS need to be connected with the 
> controller through BGP-LS.
> 
> With the existing BGP-LS extension draft, it is certainly one solution to 
> configure BGP sessions between all the service function nodes and controller, 
> and each node sends the SF information to the controller individually.
> 
> And if I get you right, we can also select one node to have a BGP session 
> with the controller and configure BGP sessions between the selected node and 
> SF nodes.
> 
> But how the selected node get the SF information from SF nodes via BGP needs 
> to be solved, since BGP-LS is typically used for exchanging information 
> between the south and north rather than nodes of the same level, and there's 
> no other existing BGP extension for distribute SIDs information between nodes 
> .
> 
> This draft aims to provide an alternate way if the operators prefer running 
> IGP on SF nodes.
> 
> So we would like to collect comments on the WG session to see how others 
> think about it.
> 
> 
> 
> Regards,
> 
> Yao
> 
> 
> 
> 
> 
> 
> 
> 原始邮件
> 发件人：AceeLindem(acee) 
> 收件人：刘尧00165286;zzhang_i...@hotmail.com ;
> 抄送人：lsr@ietf.org ;
> 日 期 ：2020年07月29日 01:53
> 主 题 ："IGP Extensions for Segment Routing Service Segment" 
> -draft-lz-lsr-igp-sr-service-segments-02
> Speaking as WG member:
> 
>  
> 
> It seems the sole purpose of this draft is to get service segment information 
> from nodes in the IGP domain to the IGP node that has a BGP session with the 
> controller. You don’t need to put this information into the IGP in order to 
> do this. Simply configure BGP sessions for the BGP-LS AF between the nodes 
> with service functions and the node selected to have a BGP session with the 
> controller.
> 
>  
> 
> Speaking as WG Chair – please let me know if we can omit this draft from the 
> agenda.
> 
>  
> 
> Thanks,
> 
> Acee
> 
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

[Hannes Gredler]

Hi Tony,

I do share Les’ concerns on burning top-level 8-bit code point space at this 
point.

At this point it is not me to judge wether CAP TLV or GENAPP TLV or something 
else should be a more appropriate place.
Please let's have a WG discussion on this.

Thanks,

/hannes

> On 21.06.2020, at 18:50, tony...@tony.li wrote:
> 
> 
> Les,
> 
>> We don’t have to resolve this now.
>> One of my motivations for sending this was related to Early Allocation of 
>> code points. Since you have already asked once, I am assuming that if WG 
>> adoption is achieved it will be swiftly followed by an early allocation 
>> request – and as one of the Designated Experts I wanted to share my concerns 
>> sooner rather than later.
> 
> 
> I appreciate that.  Do others share Les’ perspective on the relative 
> tradeoffs?  Especially our other Desginated Experts?
> 
> 
>> Would this argue for advertising “this is a boundary circuit” in pseudo-node 
>> LSPs for boundary circuits rather than advertising “inside” on all inside 
>> pseudo-nodes?
>>   
>> You could do it that way.  It inverts the semantics and inverts the 
>> deployment.  Logically, it should have the same effect.  However, it then is 
>> seen by outside nodes.  Since they need not support Area Proxy, this seemed 
>> like a riskier approach, thus we opted for marking inside pseudonodes.
>>  
>> [Les:] My point was largely motivated by the statement in the draft:
>>  
>> “Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
>>mode) with multiple Inside Edge Routers on them are not supported.”
>>  
>> So it seems advantageous to be able to prevent this from happening – which 
>> requires some signaling on the circuit in question.
> 
> 
> 
> I think that the case that you’re concerned about is already easily detected. 
>  Recall that an Inside Edge router will generate IIH’s onto a boundary 
> circuit using the Proxy system ID.  Thus, if an Inside Edge router receives 
> an IIH with a source address of it’s own proxy system id, then it has 
> encountered this issue.
> 
> Tony
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] Request for Working Group Adoption: Area Proxy

[Hannes Gredler]

support

Sent from my iPhone

> On 04.06.2020, at 18:43, tony...@tony.li wrote:
> 
> 
> 
> Dear Gentlebeings,
> 
> I would like to formally request working group adoption of “Area Proxy for 
> IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03).
> 
> The goal of this work is to improve scalability of IS-IS when transit L1 
> areas are in use.  In legacy IS-IS, for the L1 area topology to be utilized 
> by L2, part of the topology must be configured as both Level 1 and Level 2. 
> In the case where the transit topology is most or all of the L1 area, this 
> creates a scalability issue as the size of the L2 LSDB approaches that of the 
> entire network.
> 
> We propose to address this by injecting only a single LSP into Level 2. We 
> call this the Proxy LSP and it contains all reachability information for the 
> L1 area plus connectivity from the L1 area to L2 adjacencies. The result is 
> that the L1 area is now opaque, reachable, and fully capable of providing L2 
> transit.
> 
> Our use case is the deployment of Clos topologies (e.g., spine-leaf 
> topologies) as transit nodes, allowing these topologies to replace individual 
> routers. We also see applications of this approach to abstract entire data 
> centers or POPs as single nodes within the L2 area.
> 
> There are two other proposals of note before the working group.
> 
> In Topology Transparent Zones 
> (https://tools.ietf.org/html/draft-chen-isis-ttz-08), an area (or zone) may 
> be represented by a single node or as a full mesh of tunnels between the 
> edges of the zone. In addition, there is a mechanism to attempt to seamlessly 
> enable and disable the effectiveness of the zone. Relative to our proposal 
> and for our use cases, the full mesh of tunnels is not as effective at 
> providing scalability. In the specific case of spine-leaf networks, the 
> leaves are typically the majority of the nodes in the network. As they become 
> the edges of the area, with the full mesh approach, the majority of the area 
> is not abstracted out of the L2 LSDB. For our use case, we have concerns 
> about enabling and disabling the abstraction mechanism. There is added 
> complexity to support this mechanism. In networks at scale, disabling 
> abstraction may cause scalability failures. Enabling abstraction may cause 
> failures as LSPs age out at dissimlar times. We feel that establishing 
> abstraction is fundamental to the architecture of the network and that 
> changing it on the fly is a highly risky operation, best suited for 
> maintenance windows. Accordingly, the additional complexity of the transition 
> mechanism is not required.
> 
> In IS-IS Flood Reflection 
> (https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01), 
> abstraction is achieved by mechanisms similar to ours, but transit service is 
> achieved by tunneling transit traffic. That’s not necessary in our propsal.  
> In Flood Reduction, the also is coupled to the flooding reduction, whereas in 
> our proposal, the two are independent, tho they do share the Area Leader 
> mechanism.
> 
> While both of these proposals are very worthy, we believe that our proposal 
> has substantial merit. We ask that the WG adopt Area Proxy for further work.
> 
> Regards,
> Tony & Sarah
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07

[Hannes Gredler]

support

> On 02.12.2018, at 01:54, Acee Lindem (acee)  wrote:
> 
> This begins a two-week WG adoption call for the subject draft. As anyone who 
> has been following the topic knows, there are a lot of proposal in this 
> space. However, as WG co-chair, I believe this simple IS-IS extension doesn’t 
> really conflict with any of the other more disruptive flooding proposals. 
> Also, it is more mature and there is some implementation momentum. Note that 
> I’m making every attempt to be transparent and it is perfectly ok to disagree 
> with me. Please post your comments to this list before 12:00 AM, December 
> 16th, 2018.
>  
> With respect to the more disruptive proposals, we are discussing our next 
> steps.
>  
> Thanks,
> Acee
> ___
> 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] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Hannes Gredler]

I'm not aware of any IPR that has not been previously disclosed

> On 19.06.2018, at 19:07, Clarence Filsfils (cfilsfil) 
>  wrote:
> 
> I'm not aware of any IPR that has not been previously disclosed
> 
> Cheers,
> Clarence
> 
>> On 11/06/2018 21:18, Uma Chunduri wrote:
>> Dear All,
>> Are you aware of any IPR that applies to
>> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ?
>> Sending this email as suggested by LSR chairs - as this was not noticed 
>> during/around WGLC.
>> ===
>> 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.
>> ===
>> --
>> Uma C.
> 
> ___
> 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] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

[Hannes Gredler]

i am not aware of undisclosed IPR.

> On 11.06.2018, at 21:18, Uma Chunduri  wrote:
> 
> Dear All,
> 
> Are you aware of any IPR that applies to 
> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ? 
> 
> Sending this email as suggested by LSR chairs - as this was not noticed 
> during/around WGLC.
> 
> ===
> 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.
> ===
> 
> --
> Uma C.
> ___
> 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] IPR Poll for "OSPFv3 Extensions for Segment Routing" Prior to WG Last Call

[Hannes Gredler]

not aware of any undisclosed IPR

> On 22.05.2018, at 16:43, Acee Lindem (acee)  wrote:
> 
> Are you aware of any IPR that applies to
> draft-ietf-ospf-ospfv3-segment-routing-extensions-12.txt?
>  
> 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