Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt
The announcement prompted me to look again and think about an interaction between this and the network programming draft. To be clear, I am NOT objecting to either this or the network programming draft. I am just wondering what I am missing. The NP draft, and the advertisement mechanism allows a router to advertise the number of bits for the ARG portion of a SID. Q1: The point presumably is to avoid needing to advertise each of the individual values? An example of this is, I think, and ARG for the table selection where the ARG is the table number for the packet to be looked up in? Q2: If so, how does the head end know what table number corresponds to what meaning?If this requires a separate advertisement there seems to be no savings. if this requires out-of-band knowledge then we seem to have lost the benefit of advertising all of this in the routing protocol. I suspect I am simply missing a piece. can someone explain please? Thank you, Joel On 9/23/2020 4:40 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Extension to Support Segment Routing over IPv6 Dataplane Authors : Peter Psenak Clarence Filsfils Ahmed Bashandy Bruno Decraene Zhibo Hu Filename: draft-ietf-lsr-isis-srv6-extensions-10.txt Pages : 25 Date: 2020-09-23 Abstract: Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Given that the documents that provide the basic definitions needed for this are still active Internet Drafts, it seems premature to last call this document. As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, which defines the terms needed to understand this draft, is an Informative reference. Yours, Joel PS: I considered not writing this email, as it seems quite reasonable to use MT to support what I expect NRPs to be. So in principle I think the document is a good idea. On 1/10/2024 6:12 PM, Acee Lindem wrote: Note that we are last calling this informational document relating to IS-IS deployment of NRPs using multi-topology. If you have comments, please send them to the LSR list. Thanks, Acee Begin forwarded message: *From: *Acee Lindem *Subject: **Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06* *Date: *January 8, 2024 at 5:50:21 PM EST *To: *Lsr This begins a two week LSR Working Group last call for the “Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)”. Please express your support or objection prior to Tuesday, January 23rd, 2024. Thanks, Acee ___ Teas mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/teas___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
chanism described in this document complies to the design principles discussed in draft-ietf-teas-nrp-scalability and provides a valid solution for building NRPs in a limited scope. Hope this solves your concerns about the maturity and scalability of this mechanism. Best regards, Chongfeng From: Les Ginsberg \(ginsberg\) Date: 2024-01-11 08:21 To: Joel Halpern; Acee Lindem; t...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 (NOTE: I am replying to Joel’s post rather than the original last call email because I share some of Joel’s concerns – though my opinion on the merits of the draft is very different. Also, I want to be sure the TEAS WG gets to see this email.) I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt. It is certainly true, as Joel points out, that this draft references many drafts which are not yet RFCs – and in some cases are not even WG documents. Therefore, it is definitely premature to last call this draft. I also want to point out that the direction TEAS WG has moved to recommends that routing protocols NOT be used as a means of supporting NRP. https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl states: “…it is desirable for NRPs to have no more than small impact (zero being preferred) on the IGP information that is propagated today, and to not required additional SPF computations beyond those that are already required.” https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl states: “The routing protocols (IGP or BGP) do not need to be involved in any of these points, and it is important to isolate them from these aspects in order that there is no impact on scaling or stability.” Another draft which is referenced is https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ - which is not a WG document and – based on the recommendations in draft-ietf-teas-nrp-scalability – I would argue that the IGPs should NOT be extended as proposed in this draft. So if a WG adoption call were to initiated for draft-dong-lsr-sr-enhanced-vpn, I would oppose it. This then puts draft-ietf-lsr-isis-sr-vtn-mt in the position of publishing information about a solution which the IETF is discouraging. I do not know why the IETF would want to do this. If, despite all of the above, at some point it is judged not premature to publish this draft, I think the draft should at least include statements indicating that this approach is not a recommended deployment solution. Les From: Lsr On Behalf Of Joel Halpern Sent: Wednesday, January 10, 2024 3:22 PM To: Acee Lindem ; t...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Given that the documents that provide the basic definitions needed for this are still active Internet Drafts, it seems premature to last call this document. As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, which defines the terms needed to understand this draft, is an Informative reference. Yours, Joel PS: I considered not writing this email, as it seems quite reasonable to use MT to support what I expect NRPs to be. So in principle I think the document is a good idea. On 1/10/2024 6:12 PM, Acee Lindem wrote: Note that we are last calling this informational document relating to IS-IS deployment of NRPs using multi-topology. If you have comments, please send them to the LSR list. Thanks, Acee Begin forwarded message: From: Acee Lindem Subject: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Date: January 8, 2024 at 5:50:21 PM EST To: Lsr This begins a two week LSR Working Group last call for the “Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)”. Please express your support or objection prior to Tuesday, January 23rd, 2024. Thanks, Acee ___ Teas mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/teas ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Erik Kline's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS)
None of the cases you described are used for routing. And advertising information for which we do not know the use seems a bad idea. The abstraction that lets us talk about func bits and arg bits is nice. But in fact, the operational structures do not depend upon that. I really think removing section 9 would improve the document and operations. Yours, Joel On 5/20/2021 10:10 AM, Peter Psenak wrote: Joel, On 20/05/2021 15:59, Joel M. Halpern wrote: I have been watching this debate, and I am left with the impression that the information being defined in section 9 of this draft is simply not useful for routing. It confuses operational information with routing information. Given taht the information has to come from somewhere outside the router anyway, the information comes from the router, that is where the SRv6 SID is allocated. Similar to a prefix that is configured on the router and is advertised together with some additional attributes (e.g. tag). These attributes may or may not be used for routing. thanks, Peter iand that it is not going to be consumed by the routers who receive the advertisements, why is it here? Yours, Joel On 5/20/2021 7:49 AM, Peter Psenak wrote: Hi Erik, thanks for your comment, please see inline: On 19/05/2021 03:58, Erik Kline via Datatracker wrote: Erik Kline has entered the following ballot position for draft-ietf-lsr-isis-srv6-extensions-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ -- DISCUSS: -- [ section 9 ] * I share the concerns of several of the others here about SRv6 SIDs being claimed to be IPv6 addresses but kinda not really being IPv6 addresses if their internal structure is exposed outside of the given SR router. SRv6 SIDs are indeed IPv6 addresses. RFC8986 introduced the SRv6 SID structure. It also goes into allocation of SIDs where it describes the carving out of the Block for SRv6 SIDs in the domain, followed by the allocation of SRv6 Locators to the nodes in the domain. Then the node allocates the function part when instantiating the SID - and all of this is signaled via control plane protocols. This is all exposed and know to the operator who determines the addressing scheme. If "[i]t's usage is outside of the scope of this document", can this be removed for now, and maybe take up the issue at some point in the future by which time a motivating use case might have presented itself? The use-cases have not been described in this document since they were out of the scope of the ISIS protocol operations. Some of the use-cases discussed have been : - automation and verification of blocks/locators and setup of filtering for them at SR domain boundaries - validation of SRv6 SIDs being instantiated and advertised via IGP; these can be learnt by apps/controllers via BGP-LS and then monitored for conformance to the addressing rules set by the operator. - verification and even determination of summary routes to be used for covering the SRv6 Locators and SIDs. There may be other use-cases that may be operator or vendor specific. The use-cases are not within the scope of ISIS protocol extensions and are either operational or implementation specific – hence we said it was out of the scope of this document. If you feel adding these to the document may help to clear your concerns, I can certainly add them. thanks, Peter ___ 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: I-D Action: draft-liu-lsr-p2poverlan-00.txt
received an IF Type assignment
from IANA (with expert review) for point-to-point over Ethernet links several
weeks ago and the p2pOverLan type is already added to IANA registry now;
During the discussion around the assignment we noticed a doc
describing why that is needed and how to use that would be helpful;
For example, if no entry saying p2pOverLan layer over ethernet, the
management will suffer since lose the ability to get to the Ethernet-specific
management properties (Ethernet MIB or YANG model) via many tools; So
we propose this draft to define a complete p2pOverLan ifStack(Including
higher layer and lower layer);
Brs
-Original Message-
From: mohamed.boucad...@orange.com
Sent: Thursday, June 17, 2021 2:16 PM
To: Joel M. Halpern ; draft-liu-lsr-
p2pover...@ietf.org
Subject: RE: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Hi Joel, all,
Please find some quick comments to this draft, fwiw:
* pdf: https://protect2.fireeye.com/v1/url?k=e8e7d1aa-b77ce948-
e8e79131-86073b36ea28-edbd778070bbec9a&q=1&e=d4a020c9-b337-41fd-
bf1b-56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-
Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-
rev%2520Med.pdf
* doc: https://protect2.fireeye.com/v1/url?k=938b5849-cc1060ab-
938b18d2-86073b36ea28-e0406a2599fa2a6d&q=1&e=d4a020c9-b337-41fd-
bf1b-56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-
Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-
rev%2520Med.docx
Cheers,
Med
-Message d'origine-
De : Lsr [mailto:lsr-boun...@ietf.org] De la part de Joel M. Halpern
Envoyé : mercredi 16 juin 2021 22:47 À : Acee Lindem (acee)
; lsr@ietf.org Objet : Re: [Lsr] Fwd: I-D Action:
draft-liu-lsr-p2poverlan-00.txt
This document (and the code point) are intended to be in line with
5309.
I believe they are. If we got it wrong, please help us fix it.
A reference would be reasonable to add. (The IANA entry for the code
point does reference 5309.)
Thank you,
Joel
On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote:
Hi Joel,
At first I wondered where this document should reside and then
decided that LSR is probably as good as any other place.
Can you guys check whether it is mostly in line with
https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it
should be referenced?
Thanks,
Acee
On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern"
boun...@ietf.org on behalf of j...@joelhalpern.com> wrote:
Recently, Ericsson requested and received an IF Type
assignment from
IANA (with expert review) for point-to-point over Ethernet
links.
It was noted during the discussion around the assignment that
a document
(eventually, we hope, an RFC) describing how to use that and
why we
asked for it would be helpful.
The below announcement is that draft. We would like to work
with the
community to improve and clarify teh draft.
Thank you,
Joel
Forwarded Message
Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Date: Wed, 16 Jun 2021 07:00:04 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
A New Internet-Draft is available from the on-line Internet-
Drafts
directories.
Title : Interface Stack Table Definition
for Point to
Point (P2P) Interface over LAN
Authors : Daiying Liu
Joel Halpern
Congjie Zhang
Filename: draft-liu-lsr-p2poverlan-00.txt
Pages : 7
Date: 2021-06-16
Abstract:
The point-to-point circuit type is one of the mainly used
circuit
types in link state routing protocol. It is important to
identify
the correct circuit type when forming adjacencies,
flooding link
state database packets, and monitor the link state. This
document
defines point-to-point interface type and relevant stack
tables to
provide benefit for operation, maintenance and
statistics.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-liu-lsr-
p2poverlan-00
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
The change Tom has proposed to the IANA considerations section is fine with me. If there are other specific changes that will make it clearer, I and my co-authors are happy to make those. I have tried looking at the text. Even before you found it misleading, I did conclude that Tom getting the wrong impression meant it needs to be clarified. But as I am having trouble seeing what misled you, I can not suggest wording improvements to my co-authors. I presume from your phrasing that you want more changes than just to the IANA considerations section. I presume I am just being dense in not seeing the rest. I apologize, but that does not make me less dense. Sorry. Help? Joel On 6/21/2021 11:28 AM, Les Ginsberg (ginsberg) wrote: Joel - I am not objecting to the draft. I am simply asking for it to be both clear and accurate in what it is actually doing. I think Tom has done an excellent job of pointing out the inaccuracies and in some cases providing proposed revised text. I would ask you to reread your own draft in the context that at least two people have read it and found it inaccurate and both of us have made very explicit points about what language is confusing. Les -Original Message- From: Joel Halpern Direct Sent: Monday, June 21, 2021 8:13 AM To: Les Ginsberg (ginsberg) ; tom petch ; Harold Liu ; lsr@ietf.org Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt Les, I am missing something ion both your and Tom's comments. 5309 didn't define the ifType. If you look at 5309, it has no IANA considerations at all. Yes, this document should talk about 5309 as one of the cases that the ifType simplifies. And it does. This documents follows the lead of 8343 in defining this specific ifType. Let's be clear. We were asked, quite reasoanbly, by the expert, when we requested the IANA code point, to please submit a document describing how the dcode point would be used, rather than merely pointing at 5309 and assuming everyone could guess correctly. (Guessing is not good for standards.) So we are trying to do so. You seem to be objecting to our doing so. Why? If the working group really doesn't want a description, we can go away. We have the code point we felt was useful. But it seems much more useful to actually provide meaningful documentation. Yours, Joel On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote: I am in complete agreement with the points Tom has made. AFAICT, the only new content in this draft is Section 4 - the rest is either boilerplate or a repetition of text already present in RFC 5309 or RFC 8343. Neither the Abstract nor the Introduction makes that clear. The abstract actually claims to "defines point-to-point interface type" which is both FALSE (already defined in RFC 5309) and incorrectly named - since the document is actually discussing "point-to-point operation over LAN". Regarding the IANA section, it is clear that the draft is NOT creating new entries - rather it is modifying existing entries. And it isn’t modifying the code points, the names, or the descriptions - it only seeks to modify the references to include "this document". But the text in the IANA section states otherwise: " IANA need to update the "Interface Types(ifType)" registry...with the following status types" I don’t know whether the content in Section 4 is sufficient to claim a reference, but if it is it should only be in addition to the existing reference. Les -Original Message- From: Lsr On Behalf Of Joel M. Halpern Sent: Monday, June 21, 2021 7:13 AM To: tom petch ; Harold Liu ; lsr@ietf.org Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt Tom, 5309 did not define the ifType. Go read 5309. You seem to have gotten confused by the fact that the IANA entry given to 303 points to 5309. That was done to have some reference (with the consent of the experts). What we are doing now is providing a better reference. So yes, this document defines how the ifType is defined. With no criticism of 5309, it does not define that, since it does not define the ifType. We are explicit in this draft that one of the obvious uses for this ifType is to trigger 5309 behavior. Yours, Joel On 6/21/2021 4:41 AM, tom petch wrote: From: Lsr on behalf of Harold Liu Sent: 21 June 2021 02:01 Hi Med and All: Thanks for your helpful comments, I have updated a new version 01 to follow the comments; The main updating is: 1. More clearly described the intend of this draft in the introduction; 2. Change the reference style; 3. Refactor the reference section to make it more reasonable; 4. I haven't change "IANA Consideration" at the moment given there is lots of discussion in this part and it is still up in the air, I will change this section n
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
eady done and does so without reference, without acknowledgement. Having the same data defined in more than one place can only create confusion, in future if not now. This is a pattern and starts with the Abstract and continues throughout the I-D. Thus the Abstract claims 'this defines point-to-point interface type'. No. This type was defined in RFC5309 and you need to say that and to say what if anything you are changing in that definition. You should not reproduce text from that RFC unless you have to and then you should make it clear you are quoting. You do the same with Figure 1. This is a copy, may be accurate may be not, it does not matter, from RFC8343 with no mention thereof. You should not be reproducing such text without a good reason and then you should make it clear what is reproduced, from where and why. And as I have said already, IANA Considerations is yet again claiming to do what has already happened which can only confuse. All that is needed as I said in a separate note is to ask IANA to update two references, nothing more. Tom Petch And I would like to share more background information for this internet draft: As Joel mentioned, we requested and received an IF Type assignment from IANA (with expert review) for point-to-point over Ethernet links several weeks ago and the p2pOverLan type is already added to IANA registry now; During the discussion around the assignment we noticed a doc describing why that is needed and how to use that would be helpful; For example, if no entry saying p2pOverLan layer over ethernet, the management will suffer since lose the ability to get to the Ethernet- specific management properties (Ethernet MIB or YANG model) via many tools; So we propose this draft to define a complete p2pOverLan ifStack(Including higher layer and lower layer); Brs -Original Message- From: mohamed.boucad...@orange.com Sent: Thursday, June 17, 2021 2:16 PM To: Joel M. Halpern ; draft-liu-lsr- p2pover...@ietf.org Subject: RE: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt Hi Joel, all, Please find some quick comments to this draft, fwiw: * pdf: https://protect2.fireeye.com/v1/url?k=e8e7d1aa-b77ce948- e8e79131-86073b36ea28-edbd778070bbec9a&q=1&e=d4a020c9-b337- 41fd- bf1b- 56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF- Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00- rev%2520Med.pdf * doc: https://protect2.fireeye.com/v1/url?k=938b5849-cc1060ab- 938b18d2-86073b36ea28-e0406a2599fa2a6d&q=1&e=d4a020c9-b337- 41fd- bf1b- 56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF- Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00- rev%2520Med.docx Cheers, Med -Message d'origine- De : Lsr [mailto:lsr-boun...@ietf.org] De la part de Joel M. Halpern Envoyé : mercredi 16 juin 2021 22:47 À : Acee Lindem (acee) ; lsr@ietf.org Objet : Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt This document (and the code point) are intended to be in line with 5309. I believe they are. If we got it wrong, please help us fix it. A reference would be reasonable to add. (The IANA entry for the code point does reference 5309.) Thank you, Joel On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote: Hi Joel, At first I wondered where this document should reside and then decided that LSR is probably as good as any other place. Can you guys check whether it is mostly in line with https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it should be referenced? Thanks, Acee On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern" boun...@ietf.org on behalf of j...@joelhalpern.com> wrote: Recently, Ericsson requested and received an IF Type assignment from IANA (with expert review) for point-to-point over Ethernet links. It was noted during the discussion around the assignment that a document (eventually, we hope, an RFC) describing how to use that and why we asked for it would be helpful. The below announcement is that draft. We would like to work with the community to improve and clarify teh draft. Thank you, Joel Forwarded Message Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt Date: Wed, 16 Jun 2021 07:00:04 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft is available from the on-line Internet- Drafts directories. Title : Interface Stack Table Definition for Point to Point (P2P) Interface over LAN Authors : Daiying Liu Joel Halpern Congjie Zhang
