[Lsr] Rtgdir last call review of draft-ietf-lsr-dynamic-flooding-13

[Susan Hares via Datatracker]

Reviewer: Susan Hares
Review result: Ready

The document is written in a clear and concise manner.
The authors have done an excellent job of making a difficult subject clear and
readable.

Two technical sections should be checked against implementations of IS-IS with
dense flooding (section 6.6.2.1 and section 6.6.2.2.  I am not implementing so
this check is beyond my capabilities.

Editorial nit:
section 3, requirement 3, sentence 2.  "Just addressing a complete bipartite
topology such as K5, 8 is insufficient."  An informative reference to K5,8 or a
bipartite topology might be helpful to readers.  This is an optional editorial
comment.


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

[Lsr] Rtgdir last call review of draft-ietf-lsr-ospf-terminology-03

[Susan Hares via Datatracker]

Reviewer: Susan Hares
Review result: Ready

This is a routing directorate review. Just like other directorate review, it
should be considered as part of the last call comments by the authors, the WG
shepherd, and the AD.

Status: no editorial or textual comments.
The changes from "master-slave" relationship to a "leader-follower" provide an
excellent recontextualization of the concepts.   The text is easy to read.  As
the document stands, I have to no additional comments.



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

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Susan Hares]

Support.

This matches the IS-IS SRv6 extensions, and it is ready to publish.

Sue

From: Lsr  On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, August 10, 2022 11:22 AM
To: Acee Lindem (acee) ; lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Support. It provides necessary OSPF extensions for SRv6 which is equivalent to 
the IS-IS SRv6 extensions. Best regards, Jie  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  
‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External 
(jie.dong=40huawei@dmarc.ietf.org)
  Report This 
Email
  FAQ  GoDaddy Advanced Email Security, 
Powered by INKY

Support.

It provides necessary OSPF extensions for SRv6 which is equivalent to the IS-IS 
SRv6 extensions.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr mailto:lsr@ietf.org>>
Cc: 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.


https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] [Idr] IGP Monitoring Protocol

[Susan Hares]

Jeff:

An interim sounds like a good plan.

[IDR-chair hat]
Alvaro has indicated that since all of the proposal received on the IDR list 
are new protocol proposals,

  *   Capturing IDR’s input on BGP-LS problems and potential solutions is 
appropriate for IDR as BGP-LS home.
  *   Refining any potential non-BGP solutions is outside of the scope of IDR.

[IDR-chair hat off]
[rtgwg WG member]
I’d love to attend an interim on this topic.

Sue Hares


From: Jeff Tantsura 
Sent: Saturday, July 9, 2022 3:40 PM
To: Robert Raszuk 
Cc: Acee Lindem (acee) ; lsr ; i...@ietf.org; 
Susan Hares ; g...@ietf.org g...@ietf.org 
Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol

Speaking as RTGWG chair: Robert - I don’t think we’d have enough time to 
accommodate a good discussion during IETF114 (we got only 1 slot), however 
would be happy to provide a platform for an interim.
External (jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>)
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzBiOTRhNmZkOTYwNWI0MTE2NjdlMjdlZTRjODg2OTdlLzE2NTczOTU1NzcuNTc=#key=0e76c9fcd3ec8312944aa911e0941e13>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.
Cheers,
Jeff


On Jul 8, 2022, at 14:44, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

Yes, by all means input from the operator's community is needed. It can be 
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
have already seen input from some operators and their opinion on adding and 
distributing more and more link state protocol and topology data in BGP. More 
such input is very welcome.

And to your point about RFC9086 - I see nothing wrong in keeping BGP 
information in BGP. So IGP Monitoring Protocol does not target to shut down 
BGP-LS. It only aims to remove 100% of non BGP sourced information from it.

Controllers which today listen to BGP-LS need a number of information sources 
and that spread will only keep increasing as more inputs are becoming necessary 
for its computations.

Regards,
Robert.


On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Friday, July 8, 2022 at 4:36 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: lsr mailto:lsr@ietf.org>>, IDR List 
mailto:i...@ietf.org>>, Susan Hares 
mailto:sha...@ndzh.com>>
Subject: Re: [Lsr] IGP Monitoring Protocol

Hi Acee,

Thank you. I was not planning to present it in the upcoming IETF.

> Let’s see how many stakeholders actually want to this protocol - then we can 
> talk about a WG home.

An alternative approach could be to see how many stakeholders do not want to 
further (for no good reason) to trash BGP. That to me would be in this specific 
case a much better gauge.

In that case, it seems to me that this discussion should be relegated to IDR. 
Note that there is already non-IGP information transported in BGP-LS, e.g., 
Egress Peer Engineering 
(https://datatracker.ietf.org/doc/rfc9086/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org=h.eJxFjUESgyAQBL9icU6xYATEk19ZYVGj0RRuLknl75Fccp2u7nmLZ15FV4mJ-XF0ABEZOWNYKMuZOMk9jxD3ADkFr1oL4lKJpRgb8cm0Mq31uoZjwkxHv8XXJMN-BzX4Bm2K3iozNFpb66h2RE1oT8ERaGvc1RvjnDSuVKlUb5QS48a_836847yWXOGx8P_y-QJgjDiB.MEYCIQDM6a0IOMWEXn6_ra1IUbYdb6F_1qasOPtoUIKNO9acUgIhAK18nnvOVlb_6HIEZaqORgTvLo0EowqQxZEXvck3wI3m>).
 I implemented this on our data center routers (NXOS) years and it is solely 
BGP specific.

Thanks,
Acee

Kind regards,
Robert


On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as WG chair:

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Friday, July 8, 2022 at 3:21 PM
To: lsr mailto:lsr@ietf.org>>
Cc: IDR List mailto:i...@ietf.org>>, Susan Hares 
mailto:sha...@ndzh.com>>
Subject: [Lsr] IGP Monitoring Protocol

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-

Re: [Lsr] Request 5-10 minutes

[Susan Hares]

Acee:

Agreed.  All IDR and LSR chairs must agree to
the description of the process and presentation.

Or we’ll revert to the old procedure (BGP-LS TLVS
specified in IDR draft and LSR drafts).

Sue

PS – Just trying to get a jump on IETF-114 work.

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Thursday, June 30, 2022 12:54 PM
To: Susan Hares ; lsr@ietf.org
Subject: Re: [Lsr] Request 5-10 minutes

We will reserve time on the agenda for this since it is important. However, I’d 
hope we (the LSR chairs) would be involved as well. Thanks, Acee  ‌  ‌  ‌  ‌  ‌ 
 ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External 
(acee=40cisco@dmarc.ietf.org<mailto:acee=40cisco@dmarc.ietf.org>)
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzgwNzA3OTc0MjdiMjkwOGIwYWY4ZTNiNGJlMWU4YzEwLzE2NTY2MDgwNzcuNg==#key=90471fd40456cd3f758cae7d7f95a8e9>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

We will reserve  time on the agenda for this since it is important. However, 
I’d hope we (the LSR chairs) would be involved as well.
Thanks,
Acee

From: Susan Hares mailto:sha...@ndzh.com>>
Date: Thursday, June 30, 2022 at 12:51 PM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Request 5-10 minutes

Acee:

A presentation on the rules for included BGP-LS TLVs in
LSR drafts will not occur in IDR or LSR unless you and Chris both agree
with the slides and the content of the slides.

If you do not have time in LSR – we will provide time
In IDR WG for Q on the topic.

Based on the feedback on the adoption call for
draft-head-idr-bgp-ls-isis-fr-00.txt
(now: draft-ietf-idr-bgp-ls-isis-flood-reduction-00.txt),
it appears the IDR chairs were unclear about the rules
for including BGP-LS TLVs in LSR specifications.

It seems wise to clarify these rules for BGP-LS TLVs
for LSR and IDR.

If we do not have consensus within the LSR and IDR chairs
on the rules for BGP-LS TLVs In LSR drafts by IETF-114,
we will go back to the previous mechanism of
requiring drafts in LSR and IDR.

Cheers, Sue

PS – I was going to work on the slides and a YouTube
Video for the slides this weekend.

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Thursday, June 30, 2022 12:37 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Request 5-10 minutes


Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs?
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Thursday, June 30, 2022 at 12:24 PM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [Lsr] Request 5-10 minutes

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

Re: [Lsr] Request 5-10 minutes

[Susan Hares]

Acee:

A presentation on the rules for included BGP-LS TLVs in
LSR drafts will not occur in IDR or LSR unless you and Chris both agree
with the slides and the content of the slides.

If you do not have time in LSR – we will provide time
In IDR WG for Q on the topic.

Based on the feedback on the adoption call for
draft-head-idr-bgp-ls-isis-fr-00.txt
(now: draft-ietf-idr-bgp-ls-isis-flood-reduction-00.txt),
it appears the IDR chairs were unclear about the rules
for including BGP-LS TLVs in LSR specifications.

It seems wise to clarify these rules for BGP-LS TLVs
for LSR and IDR.

If we do not have consensus within the LSR and IDR chairs
on the rules for BGP-LS TLVs In LSR drafts by IETF-114,
we will go back to the previous mechanism of
requiring drafts in LSR and IDR.

Cheers, Sue

PS – I was going to work on the slides and a YouTube
Video for the slides this weekend.

From: Acee Lindem (acee) 
Sent: Thursday, June 30, 2022 12:37 PM
To: Susan Hares ; lsr@ietf.org
Subject: Re: [Lsr] Request 5-10 minutes

Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs? Acee  ‌  ‌  ‌  
‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External (a...@cisco.com<mailto:a...@cisco.com>)
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzUyYzg2YzFhYzEyMGJkMjMzMzBlZWM0NjMxNzkxZmFiLzE2NTY2MDcwMTIuMjU=#key=bed1578e10ef7376e9680b49f79301fc>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs?
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Thursday, June 30, 2022 at 12:24 PM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: [Lsr] Request 5-10 minutes

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

[Lsr] Request 5-10 minutes

[Susan Hares]

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Susan Hares]

Greetings:

I want to thank all the people who contributed to this WG adoption call.

There are four points I pull from the adoption call:

1. IDR participants desire to discuss other potential ways to pass data 
currently past in IDR

I will start a thread noted as “BGP-LS” alternative.   This thread has 2 
subjects:
1) clear problem statements on BGP-LS
2) Discussion of alternatives (e.g. Droid (draft-li-lsr-droid-00.txt)

If there is enough on list discussion, IDR may hold an interim on the topic.

2.  Operators wish to deploy this draft

I have confirmation on requests for deploying this draft.
Like some other BGP features, it may not be widely deployed.

3. The WG wishes to add these features to this experimental draft.

draft-ietf-idr-bgp-ls-isis-flood-reflection-00.txt

Based on the call, this draft should include the changes promised on the call.
The authors should resubmit the draft with this name.

4. The IDR + LSR chairs should review the agreements relating to
BGP-LS TLVs at IETF-114 in their WG.

The IDR chairs will request a time at IDR + LSR for this topic.
Let  me know if a short video be better than slides.
If so, we’ll post the video on YouTube before IETF and
Take questions at LSR or IDR.

Cheers, Sue Hares

From: Lsr  On Behalf Of Susan Hares
Sent: Friday, June 24, 2022 9:29 AM
To: Tony Przygienda ; Ketan Talaulikar 

Cc: Jordan Head ; i...@ietf.org; lsr 
Subject: Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call 
(6/6 to 6/20)

Tony P, Ketan and IDR WG: Thank you for input on this draft. I am closing the 
WG adoption call for this draft. The IDR Chairs will discuss the results of 
this consensus call, and Announce the results
Danger: External (sha...@ndzh.com<mailto:sha...@ndzh.com>)
Spoofed Internal Sender   
Details<https://protection.inkyphishfence.com/details?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2E5NTg4ZTlkNDg2YjRmMWM5OTE1NmY1MWFhMmQwZTZhLzE2NTYwNzc0MjQuODQ=#key=fd2a161745cea225d9689d66ded1958b>
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2E5NTg4ZTlkNDg2YjRmMWM5OTE1NmY1MWFhMmQwZTZhLzE2NTYwNzc0MjQuODQ=#key=fd2a161745cea225d9689d66ded1958b>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

Tony P, Ketan and IDR WG:

Thank you for input on this draft.
I am closing the WG adoption call for this draft.
The IDR Chairs will discuss the results of this consensus call, and
Announce the results by July 8th.

Cheers,

Sue Hares

From: Tony Przygienda mailto:tonysi...@gmail.com>>
Sent: Wednesday, June 22, 2022 12:11 PM
To: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Cc: Jordan Head mailto:jh...@juniper.net>>; Susan Hares 
mailto:sha...@ndzh.com>>; i...@ietf.org<mailto:i...@ietf.org>; 
lsr mailto:lsr@ietf.org>>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 
6/20)


hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation we 
try to put into BGP-LS here only the stuff that is strictly needed for topology 
discovery and understanding for advanced computation and nothing else. And 
hence, since the 1:1 TLV correspondence is nowhere to be seen by now if you 
look at ospf/isis encoding and what BGP-LS formats are today  your requirements 
are interesting but I'm not sure where they came from.

The flag indicates already whether something is client or reflector on an 
adjacency. cluster ID is there as well to differentiate between different 
clusters. L2 C/FR adjacencies will show up as well. good enough to understand 
topology and compute AFAIS.  All this is achievable by putting this element on 
the link TLV (the draft should explain it better, it just grabs codepoints in 
node/link/prefix & e'thing else ;-). Yes, we could annotate just the node 
assuming strict adherence to the IGP draft today but putting the element on the 
link descriptor follows the IGP spec itself and will allow to break the RFC if 
necessary later also in BGP-LS (by e.g. allowing a node to be client of two 
different clusters or even a node being reflector for 2 different clusters. 
Observe that this will not work in case of auto-discoery since that's on node 
caps ;-) But those are sutble discussions that need to be documented into the 
BGP-LS draft as procedures once adopted. Those discussions are natural and 
necessary since BGP-LS is NOT IGP  database but a distorted, simplified view 
for topology discovery. Or at least that's how it's used in reality based on 
the shortcomings of its design ;-)

As I explained, unless L1 adjacencies are being formed IMO they don't belong 
into BGP-LS FR information, otherwise will show up in BGP-LS naturally. Neither 
does IMO auto-discovery of FR.

As to mismatch of e.g. cluster ID/role. good observation but we don't send IIHs 
in BGP-LS either to discover MTU mismatch so I don't see that's wh

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Susan Hares]

Tony P, Ketan and IDR WG:

Thank you for input on this draft.
I am closing the WG adoption call for this draft.
The IDR Chairs will discuss the results of this consensus call, and
Announce the results by July 8th.

Cheers,

Sue Hares

From: Tony Przygienda 
Sent: Wednesday, June 22, 2022 12:11 PM
To: Ketan Talaulikar 
Cc: Jordan Head ; Susan Hares ; 
i...@ietf.org; lsr 
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 
6/20)

hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation we 
try to put into BGP-LS here only the stuff that is strictly needed for topology 
discovery and understanding for advanced co
External (tonysi...@gmail.com<mailto:tonysi...@gmail.com>)
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzE5MTIyOGZiY2Q2NTAwZTIwYjkzYjRmMGQxMzM5Y2ExLzE2NTU5MTQyODguNzQ=#key=487ff255afe0901b5c88f247a79a612d>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation we 
try to put into BGP-LS here only the stuff that is strictly needed for topology 
discovery and understanding for advanced computation and nothing else. And 
hence, since the 1:1 TLV correspondence is nowhere to be seen by now if you 
look at ospf/isis encoding and what BGP-LS formats are today  your requirements 
are interesting but I'm not sure where they came from.

The flag indicates already whether something is client or reflector on an 
adjacency. cluster ID is there as well to differentiate between different 
clusters. L2 C/FR adjacencies will show up as well. good enough to understand 
topology and compute AFAIS.  All this is achievable by putting this element on 
the link TLV (the draft should explain it better, it just grabs codepoints in 
node/link/prefix & e'thing else ;-). Yes, we could annotate just the node 
assuming strict adherence to the IGP draft today but putting the element on the 
link descriptor follows the IGP spec itself and will allow to break the RFC if 
necessary later also in BGP-LS (by e.g. allowing a node to be client of two 
different clusters or even a node being reflector for 2 different clusters. 
Observe that this will not work in case of auto-discoery since that's on node 
caps ;-) But those are sutble discussions that need to be documented into the 
BGP-LS draft as procedures once adopted. Those discussions are natural and 
necessary since BGP-LS is NOT IGP  database but a distorted, simplified view 
for topology discovery. Or at least that's how it's used in reality based on 
the shortcomings of its design ;-)

As I explained, unless L1 adjacencies are being formed IMO they don't belong 
into BGP-LS FR information, otherwise will show up in BGP-LS naturally. Neither 
does IMO auto-discovery of FR.

As to mismatch of e.g. cluster ID/role. good observation but we don't send IIHs 
in BGP-LS either to discover MTU mismatch so I don't see that's what BGP-LS is 
here for

-- tony

On Wed, Jun 22, 2022 at 4:44 PM Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:
Hi Tony,

I may not be the best judge, for this feature, of which of the ISIS sub-TLV 
need to get into BGP-LS and which do not. In my limited understanding of the 
feature and its deployment, the other 3 sub-TLVs would be equally useful to get 
into BGP-LS. Isn't the Flood Reflection Adjacency Sub-TLV the one that 
distinguishes a "normal" ISIS adjacency from a reflector adjacency formed over 
the tunnel? Isn't it useful to know what sort of tunnel encapsulation is being 
signaled so a discrepancy between the two ends can be detected?

I am copying LSR WG which probably is the better group than IDR to review and 
comment on this.

In any case, I am ok to go ahead and skip the inclusion of certain ISIS 
sub-TLVs in BGP-LS - they can be always added later on.

But I am not ok that while the ISIS Flood Reflection TLV has support for 
sub-TLVs, its corresponding BGP-LS ISIS Flood Reflection TLV does not allow for 
sub-TLVs. The encoding needs to be consistent. That is a show-stopper in my 
opinion.

Thanks,
Ketan


On Wed, Jun 22, 2022 at 7:29 PM Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:
Ketan, AFAIS tunnel status is not part of IGP state and should be derived from 
alternate mechanisms just like interface up/down state on the node. We don't 
carry interface up/down in BGP-LS today and should not (observe that I really 
mean admin/phy up/down and not IGP adj up/down here).  And then, those L1 
tunnels either form IGP adjacencies on them in which case you'll get them in 
BGP-LS as neighbors or they use something alternate like e.g. BFD (or nothing 
at all possibly) and at this point it will become really weird to carry in 
BGP-LS an L1 tunnel which does not have IGP adjacency on it ...

open to suggestions but AFAIS the FR/clien

Re: [Lsr] Status of draft-ietf-lsr-ospv3-srv6-extensions

[Susan Hares]

Robin:

Thank- you for responding to me.

As long as the OSPFv3 heads into WG LC at IETF114, then the BGP draft can move 
quickly forward.

It takes a long time to work to the top of Alvaro’s review queue.  He is 
willing to keep the place for the BGP document at the head of the line if I can 
get the OSPFv3 document moved forward quickly.

Thanks,
Sue

From: Lizhenbin 
Sent: Wednesday, June 15, 2022 10:20 AM
To: Susan Hares ; lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensions 

Subject: RE: [Lsr] Status of draft-ietf-lsr-ospv3-srv6-extensions

Hi Sue, Sorry for the late response. Thanks very much for your reminding. We 
co-authors are updating the draft and will refresh it soon. We will try to move 
it to WGLC in the IETF114. For the issue of
External (lizhen...@huawei.com<mailto:lizhen...@huawei.com>)
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzRlYjdhMmQ0YTM3ODhlMTQ4ZDVhZGU3ZWE0MzQ2ZTY2LzE2NTUzMDI4MTcuMDY=#key=29c47e8724eb4b276ae6a1ccc0cb8e4c>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

Hi Sue,
Sorry for the late response. Thanks very much for your reminding. We co-authors 
are updating the draft and will refresh it soon.
We will try to move it to WGLC in the IETF114. For the issue of moving BGP-LS 
without OSPFv3, I am not experienced enough to reply. Wish to learn the ADs and 
other's suggestion.


Best Regards,
Robin







李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com<mailto:lizhen...@huawei.com>
发件人：Susan Hares mailto:sha...@ndzh.com>>
收件人：lsr mailto:lsr@ietf.org>>
抄 送：draft-ietf-lsr-ospfv3-srv6-extensions 
mailto:draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>>
时 间：2022-06-07 08:31:09
主 题：[Lsr] Status of draft-ietf-lsr-ospv3-srv6-extensions

What is the status of draft-ietf-lsr-ospfv3-srv6-extensions?  Is this draft 
ready for WG LC?  Do you anticipate WG LC soon?

This draft expired on 5/23/2022. It has not be updated since 5/23.   Is this 
just an oversight for the authors?

draft-ietf-idr-bgpls-srv6-ext-09 references 
draft-ietf-lsr-ospfv3-srv6-extensions, and cannot go forward until the status 
of this draft is resolved.

Should IDR move draft-ietf-idr-bgpls-srv6-ext-09.txt forward without 
draft-ietf-lsr-ospfv3-srv6-extensions?

Sue Hares
IDR Shepherd and chair
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Status of draft-ietf-lsr-ospv3-srv6-extensions

[Susan Hares]

What is the status of draft-ietf-lsr-ospfv3-srv6-extensions?  Is this draft 
ready for WG LC?  Do you anticipate WG LC soon?

This draft expired on 5/23/2022. It has not be updated since 5/23.   Is this 
just an oversight for the authors?

draft-ietf-idr-bgpls-srv6-ext-09 references 
draft-ietf-lsr-ospfv3-srv6-extensions, and cannot go forward until the status 
of this draft is resolved.

Should IDR move draft-ietf-idr-bgpls-srv6-ext-09.txt forward without 
draft-ietf-lsr-ospfv3-srv6-extensions?

Sue Hares
IDR Shepherd and chair
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Susan Hares]

Jeff:

 

I agree your BGP-LS only deployment in the MSD document were not well defined.  
  

 

Starting a new set of work to define BGP-LS use in BGP-only is important.  If 
this document start the process to refine how BGP-only works, this will help 
defined this usage.   I stand by the agreement that the BGP-LS that exposes the 
OSPF/ISIS Link MTU proposal can be adopted in LSR.  However, this discussion 
has confirmed that the BGP-LS support for BGP-only needs some BGP focus. 

 

If there are other drafts on this topic, it would be good to suggest this 
drafts on the list.   Ketan suggested he had one. 

 

Cheers, Sue 

 

 

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
Sent: Friday, November 13, 2020 8:52 PM
To: Les Ginsberg (ginsberg)
Cc: Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski (slitkows); 
i...@ietf.org; Acee Lindem (acee); lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

 

To add to Les’s point of BGP only scenario, during MSD IESG reviews, BGP-LS 
only deployment was found not well characterized and had been removed from the 
draft. It will require much better discussion to have it included.

Regards,

Jeff





On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg)  wrote:

 

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

 

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

 

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

 

>From my perspective, WG adoption of this draft in ANY WG is premature.

This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

 

So I therefore oppose WG adoption of this draft by IDR.

 

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.

At that point we could then have a far more meaningful WG adoption call.

 

   Les

 

 

From: Idr  On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares ; 'Jeff Tantsura' ; 
'Stephane Litkowski (slitkows)' ; 
i...@ietf.org; 'Acee Lindem (acee)' 
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

 

Hi Authors,

 

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

 

Hi Sue,

 

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR. 

 

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

 

The MTU sub-TLV is used to optionally announce the MTU of a link as

   specified in [RFC6325], Section 
<https://tools.ietf.org/html/rfc6325#section-4.2.4.4>  4.2.4.4.

 

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

 

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

 

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

 

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both 

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Susan Hares]

Les: 

 

As you know, part of the chair’s duty is to determine if the authors have 
missed mentioning something in their draft proposal.  My questions were about 
the BGP-only features since it seemed obvious to me after working with the 
draft-ietf-idr-tunnel-encaps as a shepherd.   BGP has had direct routes since 
BGP-v3.  

 

There is appears to be interest in working on the BGP-only network and this 
topic.   The authors plan to resubmit the draft with a different name and 
details on BGP-only.  

 

One way to accomplish the evaluation of the “BGP only” service is to extend 
this WG Adoption call 1 week to allow discussion of that the revision that 
contains that information.   

 

Cheerily, Susan Hares 

 

 

 

 

 

 

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Friday, November 13, 2020 6:58 PM
To: Ketan Talaulikar (ketant); Susan Hares; 'Jeff Tantsura'; 'Stephane 
Litkowski (slitkows)'; i...@ietf.org; 'Acee Lindem (acee)'
Cc: lsr@ietf.org
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

 

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

 

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

 

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

 

>From my perspective, WG adoption of this draft in ANY WG is premature.

This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

 

So I therefore oppose WG adoption of this draft by IDR.

 

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.

At that point we could then have a far more meaningful WG adoption call.

 

   Les

 

 

From: Idr  On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares ; 'Jeff Tantsura' ; 
'Stephane Litkowski (slitkows)' ; 
i...@ietf.org; 'Acee Lindem (acee)' 
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

 

Hi Authors,

 

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

 

Hi Sue,

 

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR. 

 

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

 

The MTU sub-TLV is used to optionally announce the MTU of a link as

   specified in [RFC6325], Section 
<https://tools.ietf.org/html/rfc6325#section-4.2.4.4>  4.2.4.4.

 

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

 

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

 

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

 

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both the 
IGPs and BGP-LS encoding and procedures together.

 

Thanks,

Ketan

 

From: Idr  On Behalf Of Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' ; 'Stephane Litkowski (slitkows)' 
; i...

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

[Susan Hares]

I support adoption on experimental track. 

Sue Hares 

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, June 13, 2020 4:12 PM
To: Christian Hopps; lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

Speaking as WG  member:

I support WG adoption of this draft on the experimental track. I think it is 
better for the WG to move forward and get some data points on these competing 
solutions than to be gridlocked.

Thanks,
Acee

On 6/10/20, 3:28 PM, "Christian Hopps"  wrote:

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

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

Thanks,
Chris and 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] [Idr] 答复: New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

[Susan Hares]

+1  to Acee Comments from IDR co-chair.   We are trying to make life easier for 
you-all. 

Thanks, Sue 

-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, March 14, 2020 2:18 PM
To: wangyali; lsr@ietf.org
Cc: IDR List
Subject: Re: [Idr] 答复: [Lsr] New Version Notification for 
draft-wang-lsr-ospf-ifit-node-capability-02

Hi Yali,
Please add some more context to the draft as to how the information will be 
used. I say draft rather than drafts since you can really combine the OSPF 
draft, IS-IS draft, and BGP-LS draft into a single LSR document. For RFC 8379, 
we included the BGP-LS specification in the OSPF draft and the IDR chairs have 
agreed to this for simple encodings such as this one.  
Thanks,
Acee

On 3/10/20, 4:46 AM, "wangyali"  wrote:

Dear Acee,

Thanks a lot for your comments. I have revised the title of drafts and will 
take your suggestion to add more text on how to use the IFIT Capability 
information, once the submission is opened. Here is my quick reply:

IFIT is deployed in a specific domain referred as the IFIT domain. One 
network domain may consists of multiple IFIT domain. Within the IFIT domain, 
one or more IFIT-options are added into packet at the IFIT-enabled head node 
that is referred to as the “IFIT encapsulating node”. Then IFIT data fields MAY 
be updated by IFIT transit nodes that the packet traverses. Finally, the data 
fields are removed at a device that is referred to as the “IFIT decapsulating 
node”. 

The IFIT data fields must not leak to other domains. So, the IFIT 
encapsulating node need to know if the decapsulating node is able to support 
the IFIT capability. So that it can decide whether to add the IFIT-option or 
not.

The solution is similar to RFC8491. We use IGP to advertise the capability, 
so that head node can use. By using BGP-LS, a centralized controller can also 
learn the IFIT Capability of nodes to determine whether a particular IFIT 
Option type can be supported in a given network.

Best regards,
Yali

-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2020年3月9日 18:30
收件人: wangyali ; lsr@ietf.org
主题: Re: [Lsr] New Version Notification for 
draft-wang-lsr-ospf-ifit-node-capability-02

Hi Yali,

A couple of very basic comments on these drafts. They are definitely not 
ready for consideration. 

1. IFIT is never expanded as an acronym. Seems it should be as early as 
the title. 

  OSPF extensions for Advertising In-Situ Flow Information 
Telemetry (IFIT) Capability

   2. You probably could come up with a more succinct acronym for IFIT. 

   3. The has no specification of how the capabilities are used. Are they 
purely informational? 

Thanks,
Acee

 


On 3/9/20, 4:33 AM, "Lsr on behalf of wangyali"  wrote:

Dear all,

I'm Yali. Following is a new version of I-D, 
draft-wang-lsr-ospf-ifit-node-capability-02 I submitted recently.

Please let me know your questions and comments. Thank you.

>>>
Name:   draft-wang-lsr-ospf-ifit-node-capability
Revision:   02
Title:  Extensions to OSPF for Advertising IFIT Node Capability
Document date:  2020-03-09
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-ospf-ifit-node-capability-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-ifit-node-capability/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-ospf-ifit-node-capability-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-ospf-ifit-node-capability
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-ospf-ifit-node-capability-02

Abstract:
   This document defines a way for an Open Shortest Path First (OSPF)
   router originating the RI LSA to announce IFIT node capabilities
   within the entire routing domain.  A new optional TLV is extended to
   the OSPF RI Opaque LSA [RFC7770] to carry the IFIT node capability
   information.  Such advertisements enable IFIT applications in an
   operational network domain.  Here, the term "OSPF" includes both
   OSPFv2 and OSPFv3.

Best regards,
Yali WANG
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




___
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] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Susan Hares]

Aijun:

 

It is certainly useful to introduce a new draft for a virtual topology solution 
for 5G/IPRAN topologies.   However, I awaited two things prior to releasing 
that draft:  a) additional feedback on the problem statement from some key 
people and b) the hierarchical ISIS adoption. 

 

As to virtual topologies … As you indicated virtual topologies are carried in 
IGPs MT-ISIS (RFC5120).   These virtual topologies could utilize the 
hierarchical ISIS extension.   These virtual topologies could also use the 
alternate fast convergence algorithms.

 

I noticed that MT-ISIS MT IDs #3996-4096 are development, experimental, and 
proprietary features.  Perhaps deployment of the hierarchy for MT-ISIS might 
prove an good way for a network operations staff to get confidence that the 
hierarchy does not have an operational problem. Alternatively,  you could 
define a standard MT topology which specific rules for hierarchical MT-ISIS.  
Are you suggesting an standard MT topology be defined for hierarchical  ISIS?   
   

 

Susan Hares 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, August 19, 2019 5:29 AM
To: Susan Hares
Cc: lsr@ietf.org; tony...@tony.li; Robert Raszuk
Subject: Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" 
- draft-li-lsr-isis-hierarchical-isis-01

 

Hi, Susan:

It seems better to introduce one new draft to introduce your “virtual topology” 
solution, especially the control plane and forward plane behavior, how it 
interact with the deployed level 1/2 solutions.

 

I think to improve the convergence performance in large network such as 5G/IP 
RAN network is one attractive topic but we need to select/make the solutions 
being deployed easily and smoothly.

 

Aijun Wang

China Telecom


On Aug 16, 2019, at 22:23, Susan Hares  wrote:

Ajun:

 

I’ll let Tony provide his answer to your question.   Let me provide an 
alternate topology that your example might fit into

 

 <https://datatracker.ietf.org/doc/draft-hares-lsr-grid-ring-convergence/> 
draft-hares-lsr-grid-ring-convergence-00.txt describes a problem with IGP 
convergence for the grid-ring phone topology that may be deployed in some 5G 
networks.  One way to solve the convergence problem is to provide an alternate 
fast convergence topology that uses hierarchy to provide shorter paths through 
the Grid portion of the grid-ring topology.  

 

Suppose in this topology, the regular IGP (ISIS) algorithm keeps the 2 level 
hierarchy.  

 

The alternate fast convergence algorithm uses a multiple level hierarchy in 
order to provide faster convergence.   The multiple levels provide “short-cut” 
paths for the IGP in a virtual topology in the Grid topology.  As discussions 
on this forum have indicated, the fast convergence topologies run in parallel 
with the normal IGP forwarding providing an alternate forwarding path.   If you 
would like me to explain how the hierarchy can provide faster convergence for a 
grid, I can provide that explanation to you (online or offline).

 

Forwarding on the node needs to handle the multiple IGP routes.  Since  the 
fast convergence topologies provide early notification of forwarding problems 
in the normal IGP, the forward processing in the nodes might check this 
alternate topology for unknown routes.   Other ways of merging the two 
forwarding RIBs generated by the two IGPs also exist.  Since (per your example) 
R1 and R7 since the this link would be known to the regular IGP, the traffic 
could flow over this path. 

 

I hope this helps… 

 

Sue Hares 

 

PS – I would refresh the draft-hares-lsr-grid-ring-convergence-00.txt, but the 
draft submission seems to have a problem this morning.  This draft is still a 
rough draft. Some feedback I received indicates I should update sections.  

 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, August 16, 2019 2:48 AM
To: tony...@tony.li; 'Robert Raszuk'
Cc: lsr@ietf.org
Subject: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

 

Hi, Tony:

 

Would you like to elaborate this in more detail to show how you design the 
control plane hierarchically but the traffic can be transported horizontally? 
Let’s consider the following graph:

 



If, as you stated,  we connect R1 and R7 via one link(although we will not do 
so, if we design the network hierarchically), how you flood the link 
information hierarchically but let the traffic between the two connected L1 
area bypass the L2 area?

 

 

Best Regards.

 

Aijun Wang

China Telecom

 

 

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 tony...@tony.li
发送时间: 2019年8月15日 23:37
收件人: Robert Raszuk
抄送: lsr@ietf.org; Aijun Wang
主题: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

 

 

Hi Robert,

 

 

> The hierarchical arrangem

Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Susan Hares]

Ajun:

 

I’ll let Tony provide his answer to your question.   Let me provide an 
alternate topology that your example might fit into

 

  
draft-hares-lsr-grid-ring-convergence-00.txt describes a problem with IGP 
convergence for the grid-ring phone topology that may be deployed in some 5G 
networks.  One way to solve the convergence problem is to provide an alternate 
fast convergence topology that uses hierarchy to provide shorter paths through 
the Grid portion of the grid-ring topology.  

 

Suppose in this topology, the regular IGP (ISIS) algorithm keeps the 2 level 
hierarchy.  

 

The alternate fast convergence algorithm uses a multiple level hierarchy in 
order to provide faster convergence.   The multiple levels provide “short-cut” 
paths for the IGP in a virtual topology in the Grid topology.  As discussions 
on this forum have indicated, the fast convergence topologies run in parallel 
with the normal IGP forwarding providing an alternate forwarding path.   If you 
would like me to explain how the hierarchy can provide faster convergence for a 
grid, I can provide that explanation to you (online or offline).

 

Forwarding on the node needs to handle the multiple IGP routes.  Since  the 
fast convergence topologies provide early notification of forwarding problems 
in the normal IGP, the forward processing in the nodes might check this 
alternate topology for unknown routes.   Other ways of merging the two 
forwarding RIBs generated by the two IGPs also exist.  Since (per your example) 
R1 and R7 since the this link would be known to the regular IGP, the traffic 
could flow over this path. 

 

I hope this helps… 

 

Sue Hares 

 

PS – I would refresh the draft-hares-lsr-grid-ring-convergence-00.txt, but the 
draft submission seems to have a problem this morning.  This draft is still a 
rough draft. Some feedback I received indicates I should update sections.  

 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, August 16, 2019 2:48 AM
To: tony...@tony.li; 'Robert Raszuk'
Cc: lsr@ietf.org
Subject: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

 

Hi, Tony:

 

Would you like to elaborate this in more detail to show how you design the 
control plane hierarchically but the traffic can be transported horizontally? 
Let’s consider the following graph:

 



If, as you stated,  we connect R1 and R7 via one link(although we will not do 
so, if we design the network hierarchically), how you flood the link 
information hierarchically but let the traffic between the two connected L1 
area bypass the L2 area?

 

 

Best Regards.

 

Aijun Wang

China Telecom

 

 

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 tony...@tony.li
发送时间: 2019年8月15日 23:37
收件人: Robert Raszuk
抄送: lsr@ietf.org; Aijun Wang
主题: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

 

 

Hi Robert,

 

 

> The hierarchical arrangement of the control plane does NOT imply that the 
> data plane is necessarily hierarchical.  

 

Since Aijun posted his question I was trying to think of such model, but 
failed. 

 

While it is easy to envision this with DV protocols say BGP - do you have any 
pointer to a link state protocol architecture where data plane is non 
hierarchical (links do not belong to upper levels) while control plane used 
traverses multiple levels ? 

 

 

Consider any topology where two peer areas intersect.  At the intersection, 
traffic can transition between the areas without entering the parent level.

 

While I’m at it, I should also point out that the existence of hierarchy for 
the control plane does not mandate its use. This is another tool in the 
toolbox. Use the right tool for the job at hand.

 

Tony

 

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

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Susan Hares]

 

Support. 

 

Susan  Hares 

From: Lsr  on behalf of Acee Lindem 
Date: Monday, August 12, 2019 at 5:58 PM
To: "lsr@ietf.org" 
Subject: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

 

This begins a two week LSR Working Group Adoption Poll for the "Hierarchical 
IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll will end at 12:00 AM 
UTC on August 27th, 2019. Please indicate your support of objection on this 
list prior to the end of the adoption poll.

 

Thanks,

Acee

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

Re: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

[Susan Hares]

KetanYep.  That's the mechanism.  Was there another question?SueSent via the 
Samsung Galaxy S7 edge, an AT 4G LTE smartphone
 Original message From: "Ketan Talaulikar (ketant)" 
 Date: 7/26/19  11:54 AM  (GMT-05:00) To: Susan Hares 
, "Acee Lindem (acee)" , lsr@ietf.org Cc: 
i...@ietf.org, draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org Subject: RE: 
[Lsr] Regd covering BGP-LS extensions for IGP ELC drafts 

Hi Sue,
 
In this specific case, I would like to point that we would be marking an IDR WG 
document 
(https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/)
 as being “replaced” by the 2 LSR documents below.
 
https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
 
Thanks,
Ketan
 


From: Susan Hares 

Sent: 25 July 2019 22:58
To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: i...@ietf.org; draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org
Subject: RE: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts


 
Ketan and Acee:
 
The IDR co-chairs (John and I) wish to reduce the number of trivial drafts for 
BGP-LS allocations that could be done with 1 sentence.   We discussed with the 
LSR chairs (Acee and
 Chris) that it would be reasonable for LSR to do what Ketan has requested. 

 
We suggest that the WG LC is sent to IDR and LSR in case someone wants to 
discuss a concern.   The LSR chairs are capable and smart.   Acee and Chris can 
help shepherd these LSR
 drafts with BGP TLV language.  
 
Sue  
 
PS – has anyone heard if Chris Hopps is a father yet?

 
 


From: Lsr [mailto:lsr-boun...@ietf.org]
On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, July 25, 2019 6:43 PM
To: Acee Lindem (acee); lsr@ietf.org
Cc: i...@ietf.org; 
draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org
Subject: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts


 
Hi Acee/All,
 
During the LSR WG meeting on Monday, we talked about covering the BGP-LS 
aspects of the following two IGP drafts in those drafts instead of requiring a 
separate document:
 
https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
 
Originally, these IGP drafts introduced a new node capability that required a 
new BGP-LS TLV and this was captured in the IDR WG document
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/
 
However after the discussion in the LSR WG over the last few months, the 
approach has changed such that the IGP signalling is being done by introduction 
of new flags and MSD-type. This makes the corresponding
 BGP-LS updates quite trivial and as discussed in the LSR WG, I would recommend 
to add some text (proposed below) to the two IGP documents.
 
OSPF:
The OSPF extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The flags field of the OSPFv2 Extended 
Prefix TLV and the OSPFv3 PrefixOptions where the ELC Flag introduced in this 
document
 is advertised using the Prefix Attribute Flags TLV (TLV 1170) of the BGP-LS 
IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for OSPF by this document
 is advertised using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].

 
ISIS:
The IS-IS extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The Prefix Attribute Flags sub-TLV where 
the ELC Flag is introduced in this document is advertised using the Prefix 
Attribute
 Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for IS-IS by this document is advertised 
using the Node MSD TLV (TLV
 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].

 
I am copying the IDR WG and authors of the BGP-LS ERLD draft as well for their 
inputs/feedback.
 
Thanks,
Ketan
 


From: Lsr 
On Behalf Of Acee Lindem (acee)
Sent: 25 July 2019 16:28
To: lsr@ietf.org
Subject: [Lsr] IETF 105 LSR Working Group Meeting Minutes


 
I think we had some very good discussions in our sessions this week. I’ve 
uploaded the minutes for the both LSR sessions on Monday. Thanks much to 
Yingzhen Qu for taking them.

 
https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00
 
Thanks,
Acee
 

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

Re: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

[Susan Hares]

Ketan and Acee:

 

The IDR co-chairs (John and I) wish to reduce the number of trivial drafts for 
BGP-LS allocations that could be done with 1 sentence.   We discussed with the 
LSR chairs (Acee and Chris) that it would be reasonable for LSR to do what 
Ketan has requested. 

 

We suggest that the WG LC is sent to IDR and LSR in case someone wants to 
discuss a concern.   The LSR chairs are capable and smart.   Acee and Chris can 
help shepherd these LSR drafts with BGP TLV language.  

 

Sue  

 

PS – has anyone heard if Chris Hopps is a father yet? 

 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, July 25, 2019 6:43 PM
To: Acee Lindem (acee); lsr@ietf.org
Cc: i...@ietf.org; draft-ietf-idr-bgp-ls-segment-routing-...@ietf.org
Subject: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

 

Hi Acee/All,

 

During the LSR WG meeting on Monday, we talked about covering the BGP-LS 
aspects of the following two IGP drafts in those drafts instead of requiring a 
separate document:

 

https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/

https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

 

Originally, these IGP drafts introduced a new node capability that required a 
new BGP-LS TLV and this was captured in the IDR WG document 
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

 

However after the discussion in the LSR WG over the last few months, the 
approach has changed such that the IGP signalling is being done by introduction 
of new flags and MSD-type. This makes the corresponding BGP-LS updates quite 
trivial and as discussed in the LSR WG, I would recommend to add some text 
(proposed below) to the two IGP documents.

 

OSPF:

The OSPF extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The flags field of the OSPFv2 Extended 
Prefix TLV and the OSPFv3 PrefixOptions where the ELC Flag introduced in this 
document is advertised using the Prefix Attribute Flags TLV (TLV 1170) of the 
BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for OSPF by this document is advertised using 
the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].
 

 

ISIS:

The IS-IS extensions defined in this document can be advertised via BGP-LS 
[RFC7752] using existing BGP-LS TLVs. The Prefix Attribute Flags sub-TLV where 
the ELC Flag is introduced in this document is advertised using the Prefix 
Attribute Flags TLV (TLV 1170) of the BGP-LS IPv4/IPv6 Prefix NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16#section-2.3.2].
 The new ERLD MSD-type introduced for IS-IS by this document is advertised 
using the Node MSD TLV (TLV 266) of BGP-LS Node NLRI Attribute 
[https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-05#section-3].
 

 

I am copying the IDR WG and authors of the BGP-LS ERLD draft as well for their 
inputs/feedback.

 

Thanks,

Ketan

 

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 25 July 2019 16:28
To: lsr@ietf.org
Subject: [Lsr] IETF 105 LSR Working Group Meeting Minutes

 

I think we had some very good discussions in our sessions this week. I’ve 
uploaded the minutes for the both LSR sessions on Monday. Thanks much to 
Yingzhen Qu for taking them. 

 

https://datatracker.ietf.org/meeting/105/materials/minutes-105-lsr-00

 

Thanks,
Acee

 

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

Re: [Lsr] 回复： Status of draft-ietf-isis-encapsulation-cap

[Susan Hares]

Xiaohu:

 

The draft-ietf-idr-tunnel-encaps-12 is in a WG review of the final changes 
until June 7th.  After this the draft will be sent to the IESG.  You may want 
to review this final draft. 

 

Cheerily, Sue 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??)
Sent: Sunday, April 14, 2019 11:21 PM
To: adrian; lsr
Subject: Re: [Lsr] 回复： Status of draft-ietf-isis-encapsulation-cap

 

Both the OSPF and ISIS drafts have heavy dependency on the BGP counterpart 
(https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-11) which has not 
been published yet since it was adopted almost 4 years ago.

 

Best regards,

Xiaohu

 

 

 

 

 

--

From:Adrian Farrel 

Send Time:2019年4月14日(星期日) 01:09

To:徐小虎(义先) ; lsr 

Subject:Re: [Lsr] 回复： Status of draft-ietf-isis-encapsulation-cap

 

Thanks Xiaohu,

That at least indicates that you would like to see an RFC published.

 

But I wonder whether the WG has given up on this work? Two years is a long time 
to make no advances and to have no demands for publication.

I wonder why no one has cared in the interim.

 

Best,

Adrian

 

From: 徐小虎(义先)  
Sent: 13 April 2019 17:56
To: adr...@olddog.co.uk; lsr@ietf.org
Subject: 回复：[Lsr] Status of draft-ietf-isis-encapsulation-cap

 

I will update the ISIS draft soon.

Xiaohu





来自钉钉专属商务邮箱

--
发件人：Adrian Farrel
日　期：2019年04月13日 23:59:05
收件人：
主　题：[Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

https://datatracker.ietf.org/doc/draft-ietf-isis-encapsulation-cap/ shows
expired in October 2017, so I guess that is good and dead.

On the other hand,
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ found
its way onto the RFC Editor Queue at around the same date and has languished
there ever since.

Did the ISIS work get replaced by some other draft without the "replaced by"
link being set up?
Was it deemed unnecessary in ISIS?

Thanks,
Adrian (who is trying to get draft-ietf-mpls-sr-over-ip through the IESG and
finds a reference to this draft)
--
Fairy tales from North Wales for adults of all ages
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

___
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 Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

[Susan Hares]

Acee: 

 

Support.  Important for SRV6 dataplane.  IDR draft has adopted  
draft-ietf-idr-bgpls-srv6-ext-06. 

 

Sue

 

PS -  It past May 25th at 2019, but I did not see an announcement yet. 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 9, 2019 9:50 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support 
Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

 

We been holding off WG adoption until the base SRv6 draft was adopted in 
SPRING. Now that 
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ 
has been adopted, we are starting a two week LSR WG adoption poll for the 
subject draft. Please register your support or objection prior to 12:00 AM UTC, 
on May 25th, 2019.

 

For your convenience, here is a URL for the draft:

 

https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/

 

Thanks,

Acee

 

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

Re: [Lsr] *** SPAM ***Re: When to augment LSR base YANG modules...

[Susan Hares]

Rob and Acee: 

 

My apologies- I missed a vital typo. 

 

---  We can review info/data, and code functionality based on the key 
capability.

 

I’ve revised the text inline below.  

 

Sue 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Sunday, March 31, 2019 10:14 AM
To: 'Rob Shakir'; 'Acee Lindem (acee)'
Cc: lsr@ietf.org; tony...@tony.li; 'Christian Hopps'
Subject: *** SPAM ***Re: [Lsr] When to augment LSR base YANG modules...

 

Rob and Acee: 

 

I agree that with Rob that it is a generic problem that you must have a robust 
way to version and revise the Yang models.   This is true for configuration, 
operational data, and dynamic data stores.   The netmod modeling is focusing on 
configuration at this time.   

 

It is critical to determine how the base models yang models prepare for 
augmentations.  OSPF, ISIS, BGP, FIB/RIB, and policy are key models.   Since 
our protocols are augmented based on capabilities, augmentation based on the 
same capabilities for models makes the most sense.   We can review info/data, 
and code functionality based on the key capability. 

 

If we have good versioning of the base model, can revise both the data model 
and the capability independently.   If we utilize the grouping of data models 
based on the versioning, automatic deployment of this work can occur. 

 

Acee and Chris has been actively participating on the versioning discussion in 
netmod’s work on versioning.   I’m sure they can report if they feel the 
support his there for this type of version. 

 

BGP and rtgwg can integrate this type of version prior to the upcoming WG LC. 

 

Sue  

 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Saturday, March 30, 2019 2:00 PM
To: Acee Lindem (acee)
Cc: lsr@ietf.org; tony...@tony.li; Christian Hopps
Subject: Re: [Lsr] When to augment LSR base YANG modules...

 

I think this is a generic challenge that has to be solved across all protocols 
-- and relies on a robust way to version and revise YANG modules in the IETF. 

 

In OpenConfig, as we're very lightweight for pushing a new revision, since 
we're just specifying new versions of modules, adding new features to an 
existing module is pretty trivial. They can be done as a minor revision if 
there's no backwards incompatible changes.  It seems better, to me, to ensure 
that there is common logic for how one splits up modules, to make things 
actually usable for developers trying to consume them, rather than needing to 
understand when and where in the IETF a feature was developed.

 

That being said -- this means one should probably expect each LSR base module 
to be revised with most new LSR RFCs. With the current agility of the review 
and publication process -- I'm not sure that is realistic either.

 

r.

 

On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee)  wrote:

Speaking as WG member:

For many of the new LSR WG documents, we are already included both OSPF and 
IS-IS encodings in a single document. Now, we have agreed that documents 
requiring simple BGP-LS changes will also include the BGP-LS encoding. Given 
this, I don't want to add another requirement for publication of a WG document. 
This would also add additional reviews to the document. You've all heard the 
expression "divide and conquer", while let me introduce the corollary, 
"consolidate and stagnate". 

Additionally, I agree with Yingzhen's comment that it is not clear that we want 
a separate YANG module for every OSPF/IS-IS feature. 

Thanks,
Acee

On 3/29/19, 4:33 AM, "Lsr on behalf of tony...@tony.li 
<mailto:tony@tony.li> "  
wrote:


Chris,

One concern is simply one of scale: doing this will increase the size of 
the document.  At what point do things become sufficiently awkward that we want 
to have a separate, concurrent document.

In other words, if the requirement is for concurrent delivery, is 
co-location really a requirement?

Regards,
Tony


> On Mar 29, 2019, at 9:17 AM, Christian Hopps  wrote:
> 
> 
> The base YANG modules for IS-IS and OSPF both include operational state 
to describe TLV data. During the discussion about OSPFv3's version of this 
data, I brought up the issue of when and how the base modules should be 
augmented to add new TLV types to the model, suggesting it be done inline and 
with the RFC that adds the new feature/functionality to the protocol.
> 
> I'll go farther here and say this should apply to all the YANG required 
for management of the new feature, and it should all be added inline with the 
feature (i.e., in the same draft). In other words new features/functionality 
should include the YANG augment required to manage said features/functionality.
> 
> This has been suggested/tried previously with SNMP with varying (low) 
levels of success. The difference here is 1) YANG additions (a new module 
perhaps just aug

Re: [Lsr] When to augment LSR base YANG modules...

[Susan Hares]

Rob and Acee: 

 

I agree that with Rob that it is a generic problem that you must have a robust 
way to version and revise the Yang models.   This is true for configuration, 
operational data, and dynamic data stores.   The netmod modeling is focusing on 
configuration at this time.   

 

It is critical to determine how the base models yang models prepare for 
augmentations.  OSPF, ISIS, BGP, FIB/RIB, and policy are key models.   Since 
our protocols are augmented based on capabilities, augmentation based on the 
same capabilities for models makes the most sense.   We can review info/data, 
and code functionality based on the key senses. 

 

If we have good versioning of the base model, can revise both the data model 
and the capability independently.   If we utilize the grouping of data models 
based on the versioning, automatic deployment of this work can occur. 

 

Acee and Chris has been actively participating on the versioning discussion in 
netmod’s work on versioning.   I’m sure they can report if they feel the 
support his there for this type of version. 

 

BGP and rtgwg can integrate this type of version prior to the upcoming WG LC. 

 

Sue  

 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Saturday, March 30, 2019 2:00 PM
To: Acee Lindem (acee)
Cc: lsr@ietf.org; tony...@tony.li; Christian Hopps
Subject: Re: [Lsr] When to augment LSR base YANG modules...

 

I think this is a generic challenge that has to be solved across all protocols 
-- and relies on a robust way to version and revise YANG modules in the IETF. 

 

In OpenConfig, as we're very lightweight for pushing a new revision, since 
we're just specifying new versions of modules, adding new features to an 
existing module is pretty trivial. They can be done as a minor revision if 
there's no backwards incompatible changes.  It seems better, to me, to ensure 
that there is common logic for how one splits up modules, to make things 
actually usable for developers trying to consume them, rather than needing to 
understand when and where in the IETF a feature was developed.

 

That being said -- this means one should probably expect each LSR base module 
to be revised with most new LSR RFCs. With the current agility of the review 
and publication process -- I'm not sure that is realistic either.

 

r.

 

On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee)  wrote:

Speaking as WG member:

For many of the new LSR WG documents, we are already included both OSPF and 
IS-IS encodings in a single document. Now, we have agreed that documents 
requiring simple BGP-LS changes will also include the BGP-LS encoding. Given 
this, I don't want to add another requirement for publication of a WG document. 
This would also add additional reviews to the document. You've all heard the 
expression "divide and conquer", while let me introduce the corollary, 
"consolidate and stagnate". 

Additionally, I agree with Yingzhen's comment that it is not clear that we want 
a separate YANG module for every OSPF/IS-IS feature. 

Thanks,
Acee

On 3/29/19, 4:33 AM, "Lsr on behalf of tony...@tony.li 
 "  
wrote:


Chris,

One concern is simply one of scale: doing this will increase the size of 
the document.  At what point do things become sufficiently awkward that we want 
to have a separate, concurrent document.

In other words, if the requirement is for concurrent delivery, is 
co-location really a requirement?

Regards,
Tony


> On Mar 29, 2019, at 9:17 AM, Christian Hopps  wrote:
> 
> 
> The base YANG modules for IS-IS and OSPF both include operational state 
to describe TLV data. During the discussion about OSPFv3's version of this 
data, I brought up the issue of when and how the base modules should be 
augmented to add new TLV types to the model, suggesting it be done inline and 
with the RFC that adds the new feature/functionality to the protocol.
> 
> I'll go farther here and say this should apply to all the YANG required 
for management of the new feature, and it should all be added inline with the 
feature (i.e., in the same draft). In other words new features/functionality 
should include the YANG augment required to manage said features/functionality.
> 
> This has been suggested/tried previously with SNMP with varying (low) 
levels of success. The difference here is 1) YANG additions (a new module 
perhaps just augmenting the base) is easy, whereas SNMP wasn't. Additionally, 
operators weren't using SNMP to fully manage functionality (e.g., not doing 
configuration) so a requirement for extra work was harder to justify. Operators 
*do* want to fully manage their networks/servers with YANG though.
> 
> The argument against this during the meeting was that it would create 
many small modules. I don't find this compelling (i.e., "so"? :)
> 
> Assume I'm an operator -- the actual consumer of this management stuff:
> 
> - If 

[Lsr] Flooding Reduction Draft Discussion - a naive question

[Susan Hares]

In working through the emails on the flooding reduction concepts,  I have a
few question:   Is this work is simply for the spine-leaf topologies or for
multiple topologies?   . Does this work consider all of the following
networks: spine-leaf data centers, 802.1 Provider Bridging, IPRAN
topologies, banking networks, and IoT sensor networks?  

 

If this technology is for multiple topologies, it is useful to have a
discussion of convergence problems within these diverse networks.   I have
observed in WG meetings and on-list the following problem scenarios: a)
spine-leaf convergence problem descriptions and b) Dave Allan's description
of the 802.1 Provider Bridging (PBB) convergence issues.   Did I miss other
problem convergence discussions?  

 

Sue

 

PS -  As part of some research for IPRAN topologies, I wrote-up a
description of convergence problems for the IPRAN ring-grid topologies.  I
am looking for something like: 

https://www.ietf.org/internet-drafts/draft-hares-lsr-grid-ring-convergence-0
0.txt

 

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

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

[Susan Hares]

Stephane, Gunter, Ketan, Les, and Jeff:

Are you going to settle on option 2?  Will we be seeing drafts with this
change in this revision? 

Sue Hares 


-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of
stephane.litkow...@orange.com
Sent: Wednesday, June 13, 2018 6:05 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp); Ketan Talaulikar (ketant);
i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: Re: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi,

As defined in draft-ietf-mpls-spring-entropy-label, advertising an ERLD
means that the node is defacto ELC (so advertising ELC separately is not
necessary):

" The Entropy Readable Label Depth (ERLD) is defined as the number of
   labels a router can both:

   a.  Read in an MPLS packet received on its incoming interface(s)
   (starting from the top of the stack).

   b.  Use in its load-balancing function.

   The ERLD means that the router will perform load-balancing using the
   EL label if the EL is placed within the ERLD first labels.
"

"
To advertise an ERLD value, a SPRING router:

   o  MUST be entropy label capable and, as a consequence, MUST apply
  the dataplane procedures defined in [RFC6790].

   o  MUST be able to read an ELI/EL which is located within its ERLD
  value.

   o  MUST take into account this EL in its load-balancing function.
"


Brgds,


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Van De Velde, Gunter
(Nokia - BE/Antwerp)
Sent: Wednesday, June 13, 2018 11:10
To: Ketan Talaulikar (ketant); i...@ietf.org; lsr@ietf.org; spr...@ietf.org
Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)

It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are
signaled for ISIS, OSPF and BGP-LS. 

If the WG's can manage to agree upon a decision (option1/2/3 or 4), then
next, have a look into how to encode the TLV so that we have a clean
technological solution space.

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Wednesday, June 13, 2018 10:45
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,

In that case, I concur with you that option (2) is better than the others.
My only difference in opinion is that ERLD not have its own separate TLV but
instead get advertised as a new MSD sub-type - it is just a different
encoding.

Thanks,
Ketan

-Original Message-
From: Van De Velde, Gunter (Nokia - BE/Antwerp)

Sent: 13 June 2018 13:55
To: Ketan Talaulikar (ketant) ; i...@ietf.org;
lsr@ietf.org; spr...@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

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
*