Chongfeng –
We are at the stage of last call.
The document has been presented and discussed previously – it is time for WG
members to render their opinions.
For folks who have actively followed/participated in the discussion, it is very
unlikely that we will alter opinions by further discussion. Which means if you
and I have different points of view it is very unlikely that I will alter your
opinion and very unlikely that you will alter mine.
In that context, I typically do not reply when someone posts their opinion and
it is different than mine. The point of last call is to get the opinions of WG
members.
In this case, however, I will respond with some clarifications – not in the
hopes of changing your mind – but only to provide additional clarity as to why
I have the opinion that I do.
The use of MT in support of NRP – at whatever scale – clearly requires
additional SPF calculations – which is something which is expressly identified
as undesirable in draft-ietf-teas-nrp-scalability.
draft-ietf-teas-nrp-scalability also states (as you have pointed out) that
“control plane extensions” are seen as undesirable.
Having implemented the use of MT for purposes other than supporting the
reserved AFI/SAFI specific topologies specified in RFC 5120, I can tell you
that there is a significant amount of “control plane work” associated with
adding such support. The fact that no new protocol extensions are required is
not the same as saying no new control plane work is required. I can assure you
that there would be a significant amount of control plane work required.
So I do see that draft-ietf-lsr-isis-sr-vtn-mt is at odds with
draft-ietf-teas-nrp-scalability.
Thanx for listening.
Les
From: Lsr <[email protected]> On Behalf Of Chongfeng Xie
Sent: Wednesday, January 10, 2024 7:41 PM
To: Les Ginsberg (ginsberg) <[email protected]>; jmh
<[email protected]>; Acee Lindem <[email protected]>; TEAS WG
<[email protected]>; lsr <[email protected]>
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
Hi Les,
Thanks for your comments.
This is an informational document which describes the applicability of existing
IS-IS MT mechanisms for building SR based NRPs. All the normative references
are either RFCs or stable WG documents. It is true that some informative
references are individual documents, while they just provide additional
information related to this topic, thus would not impact the stability and
maturity of the proposed mechanism.
The text you quoted from draft-ietf-teas-nrp-scalability are about the
considerations when the number of NRP increases, how to minimize the impact to
the routing protocols (e.g. IGP). While as described in the scalability
considerations section of this document, the benefit and limitation of using
this mechanism for NRP are analyzed, and it also sets the target scenarios of
this mechanism:
“The mechanism described in this document is considered useful for network
scenarios in which the required number of NRP is small”
Thus it is clear that this solution is not recommended for network scenarios
where the number of required NRP is large.
Please note section 3 of draft-ietf-teas-nrp-scalability also mentioned that:
“The result of this is that different operators can choose to deploy
things at different scales.”
And
“In particular, we should be open to the use of approaches that do not
require control plane extensions and that can be applied to deployments with
limited scope.”
According to the above text, we believe the mechanism 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\)<mailto:[email protected]>
Date: 2024-01-11 08:21
To: Joel Halpern<mailto:[email protected]>; Acee
Lindem<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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 <[email protected]<mailto:[email protected]>> On Behalf Of Joel
Halpern
Sent: Wednesday, January 10, 2024 3:22 PM
To: Acee Lindem <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
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 <[email protected]><mailto:[email protected]>
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 <[email protected]><mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
