Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 2 Mar 2021 23:27:44 +0000

This information draft describes how MT could be used for VTN segmentation. The authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next week. Please register your support or objection on this list prior to the end of the adoption poll on 3/24/2020.

Thanks,
Acee

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 3 Mar 2021 11:03:40 +0000

Hi,

Support the adoption as a coauthor.

This document describes a practical mechanism to use MT together with segment routing to build SR based VTNs.

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:28 AM
To: [email-masked]
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Thanks,
Acee

---

From: Huzhibo <[email-masked]>
Date: Wed, 3 Mar 2021 11:34:05 +0000

Support the adoption.

Zhibo Hu

Thanks,
Acee

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 3 Mar 2021 19:40:55 +0800

Hi, all

I support the adoption of this document. It is straightforward and reasonable to use MT to build VTNs with customized topology and attributes, and the document is well written. 

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
发件人： Acee Lindem \(acee\)
发送时间： 2021-03-03 07:27
收件人： [email-masked]
主题： [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
This information draft describes how MT could be used for VTN segmentation. The authors have asked for WG adoption. 

Thanks,
Acee

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 3 Mar 2021 19:40:55 +0800

Hi, all

Best Regards
Zongpeng Du

 
 
Thanks,
Acee

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 3 Mar 2021 16:53:44 +0000

Hi Everyone,

    I read through the document and support its adoption.

Best Regards,
Huaimo
________________________________
From: Lsr <[email-masked]> on behalf of Acee Lindem (acee) <acee=[email-masked]>
Sent: Tuesday, March 2, 2021 6:27 PM
To: [email-masked] <[email-masked]>
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Thanks,

Acee

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 3 Mar 2021 18:06:04 +0000

I support the WG Adoption of this draft.
This information draft describes how RFC5305, RFC8570 are used to advertise topology specific TE attributes, and SR VTN resource attribute. it is useful.

Linda Dunbar
From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Tuesday, March 2, 2021 5:28 PM
To: [email-masked]
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Thanks,
Acee

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 Mar 2021 03:52:03 +0000

I oppose WG adoption for this draft.

I note that the authors – following significant comments received on V0 - have removed much of the material that was considered confusing and/or inappropriate – notably discussion of L2 bundle link members.
I also note the draft has moved from Standards track to Informational track.

Let’s consider what content remains (ignoring boilerplate sections):

Section 2 notes that MT TLVs (RFC 5120) can support:
   o Topology specific SR-MPLS SIDs (defined in RFC 8667)
   o Topology specific SRv6 Locators and SIDs (defined in draft-ietf-lsr-isis-srv6-extensions)

Section 3 notes that MT TLVs can also support link attribute advertisements (defined in RFC 5305 and RFC 8570)

Also note that the IANA registries:

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 and
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237

also clearly document what is discussed in Sections 2 and 3.

Section 4 notes that topology specific forwarding entries can be installed in the forwarding plane based on topology specific routing calculations – something which was discussed in RFC 5120.

Section 5 notes that two different MTIDs could operate on the same physical topology - something clearly discussed in RFC 5120.

All of this adds nothing new to our understanding of the protocol. The only “new” content is the statement that VTNs could map to MTIDs.
But the substance of VTN and how it might be used is better discussed in a number of other drafts including:

   draft-ietf-spring-sr-for-enhanced-vpn
   draft-ietf-teas-enhanced-vpn
   draft-dong-lsr-sr-enhanced-vpn

The last draft is most notable because it proposes new IGP protocol encodings in support of VTN. Whether the encodings in that draft are accepted as currently defined or evolve to something different – it would be the authoritative draft on VTN IGP extensions.

The end result is that there is no meaningful content in draft-xie-lsr-isis-sr-vtn-mt. What it states is either already stated in existing RFCs or will be stated authoritatively in whatever draft-dong-lsr-sr-enhanced-vpn  evolves to (if indeed this work on VTNs is adopted by the WG).

Let’s please not waste WG time on this draft.

   Les

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Tuesday, March 02, 2021 3:28 PM
To: [email-masked]
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Thanks,
Acee

---

From: "Chongfeng Xie" <[email-masked]>
Date: Thu, 4 Mar 2021 21:03:38 +0800

Hi， Les,
 
Thanks for the review of this document.
 
As the current document type is informational, it does not introduce new TLV to IS-IS. While it describes the mechanisms of using existing TLVs to distribute the information of SR based VTNs, which can have customized topology and a set of dedicated network resources. It also describes the forwarding behaviors based on the SIDs and the resources allocated to each VTN.
 
IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple logical topologies and perform independent path computation for each topology. RFC 5120 mentions that the TE attributes TLVs can be inherited by the MT TLVs “if traffic engineering or some other applications are being applied per topology level later”. While it does not specify what the topology-specific TE attributes mean, and how traffic in different topologies are forwarded on a shared outgoing interface. These are described in section 3 and section 4 of this document.
 
RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs and Locators are not specified, especially when the SIDs are associated with different set of network resources.
 
Section 5 gives the analysis about the scalability of this mechanism, and talks about a case where two VTNs have the same logical topology, but with different set of resources.
 
IMO the value of this document is that it provides an option to build SR VTNs with no IS-IS protocol extensions, which could be useful for some network scenarios.
 
Best regards,
Chongfeng

[email-masked]
 
发件人： Les Ginsberg \(ginsberg\)
发送时间： 2021-03-04 11:52
收件人： Acee Lindem (acee); [email-masked]
主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
I oppose WG adoption for this draft.

 

 

 

 

 
   Les

 
 
Thanks,
Acee

---

From: Aijun Wang <[email-masked]>
Date: Thu, 4 Mar 2021 23:59:10 +0800

Hi,Les:

My understanding is that https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ proposed the necessary IGP extensions to accomplish more abundant VTN function, while this adopting draft described how to utilize the existing MT mechanism to achieve the basic VTN function.
And based on the above differences, the corresponding part of https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-05#section-3.1 should be removed and kept only in the current information draft because it doesn’t need protocol extension.

Adopting this document can certainly accelerate the deployment of MT/SR based VTN, using the existing tools invented by IETF. 

This document just tell the reader how to achieve the above goal.
Then I support its adoption.

Aijun Wang
China Telecom

> On Mar 4, 2021, at 21:04, Chongfeng Xie <[email-masked]> wrote:
> 
> 
> 
> Hi， Les,
>  
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 Mar 2021 16:17:59 +0000

Chongfeng –

Just to clarify my position…

IMO there is no substantive content in this draft that warrants it becoming an RFC – Informational track or otherwise. It is simply a set of pointers to other documents/registries.

If the authors find the content in some way helpful, I think the more suitable path for you is to publish a white paper and post it on whatever web site seems appropriate to you.
I just do not see any content in the draft that warrants a standards body like IETF producing a new document.

Thanx.

   Les

From: Chongfeng Xie <[email-masked]>
Sent: Thursday, March 04, 2021 5:04 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: Re: Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Hi， Les,

Best regards,
Chongfeng

________________________________
[email-masked]<mailto:[email-masked]>

发件人： Les Ginsberg \(ginsberg\)<mailto:ginsberg=[email-masked]>
发送时间： 2021-03-04 11:52
收件人： Acee Lindem (acee)<mailto:acee=[email-masked]>; [email-masked]<mailto:[email-masked]>
主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
I oppose WG adoption for this draft.

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
Sent: Tuesday, March 02, 2021 3:28 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Thanks,
Acee

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 5 Mar 2021 10:39:16 -0500

I support WG adoption of this document by LSR.

In the context of TEAS NS definition and VTN underlay provisioning of
network slice resources underpinning to Enhanced VPN + overlay, I believe
this draft provides and important solution as to the resource isolation and
provisioning of a network slice using existing ISIS MT instances to provide
the resource isolation framework for each discrete VTN.

I believe this same VTN provisioning could be done as well using ISIS
instances RFC 6822 or a combination of MT and ISIS instances.

With OSPFv3 as well multiple processes would have to be provisioned as the
concept of MT is MI does not exist for OSPF thus ISIS is the desired
protocol for network slicing.

https://tools.ietf.org/html/rfc6822

Kind Regards

Gyan

On Thu, Mar 4, 2021 at 11:18 AM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> IMO there is no substantive content in this draft that warrants it
> becoming an RFC – Informational track or otherwise. It is simply a set of
> pointers to other documents/registries.
>
>
>
> If the authors find the content in some way helpful, I think the more
> suitable path for you is to publish a white paper and post it on whatever
> web site seems appropriate to you.
>
> *From:* Chongfeng Xie <[email-masked]>
> *Sent:* Thursday, March 04, 2021 5:04 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <
> [email-masked]>; [email-masked]
> *Subject:* Re: Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology
> (MT) for Segment Routing based Virtual Transport Network” -
> draft-xie-lsr-isis-sr-vtn-mt-03
>
>
>
>
>
> Hi， Les,
>
>
>
> As the current document type is informational, it does not introduce new
> TLV to IS-IS. While it describes the mechanisms of using existing TLVs to
> distribute the information of SR based VTNs, which can have customized
> topology and a set of dedicated network resources. It also describes the
> forwarding behaviors based on the SIDs and the resources allocated to each
> VTN.
>
>
>
> IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple
> logical topologies and perform independent path computation for each
> topology. RFC 5120 mentions that the TE attributes TLVs can be inherited by
> the MT TLVs “if traffic engineering or some other applications are being
> applied per topology level later”. While it does not specify what the
> topology-specific TE attributes mean, and how traffic in different
> topologies are forwarded on a shared outgoing interface. These are
> described in section 3 and section 4 of this document.
>
>
>
> RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR
> SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs
> and Locators are not specified, especially when the SIDs are associated
> with different set of network resources.
>
>
>
> Section 5 gives the analysis about the scalability of this mechanism, and
> talks about a case where two VTNs have the same logical topology, but with
> different set of resources.
>
>
>
> IMO the value of this document is that it provides an option to build SR
> VTNs with no IS-IS protocol extensions, which could be useful for some
> network scenarios.
>
>
>
> Best regards,
>
> Chongfeng
>
>
> ------------------------------
>
> *发件人：* Les Ginsberg \(ginsberg\) <ginsberg=[email-masked]>
>
> *发送时间：* 2021-03-04 11:52
>
> *收件人：* Acee Lindem (acee) <acee=[email-masked]>; [email-masked]
>
> *主题：* Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for
> Segment Routing based Virtual Transport Network” -
> draft-xie-lsr-isis-sr-vtn-mt-03
>
> I note that the authors – following significant comments received on V0 -
> have removed much of the material that was considered confusing and/or
> inappropriate – notably discussion of L2 bundle link members.
>
> Section 3 notes that MT TLVs can also support link attribute
> advertisements (defined in RFC 5305 and RFC 8570)
>
>
>
> Section 4 notes that topology specific forwarding entries can be installed
> in the forwarding plane based on topology specific routing calculations –
> something which was discussed in RFC 5120.
>
>
>
> Section 5 notes that two different MTIDs could operate on the same
> physical topology - something clearly discussed in RFC 5120.
>
>
>
> All of this adds nothing new to our understanding of the protocol. The
> only “new” content is the statement that VTNs could map to MTIDs.
>
> The last draft is most notable because it proposes new IGP protocol
> encodings in support of VTN. Whether the encodings in that draft are
> accepted as currently defined or evolve to something different – it would
> be the authoritative draft on VTN IGP extensions.
>
>
>
> The end result is that there is no meaningful content in
> draft-xie-lsr-isis-sr-vtn-mt. What it states is either already stated in
> existing RFCs or will be stated authoritatively in whatever
> draft-dong-lsr-sr-enhanced-vpn  evolves to (if indeed this work on VTNs is
> adopted by the WG).
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Tuesday, March 02, 2021 3:28 PM
> *To:* [email-masked]
> *Subject:* [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT)
> for Segment Routing based Virtual Transport Network” -
> draft-xie-lsr-isis-sr-vtn-mt-03
>
>
>
> This information draft describes how MT could be used for VTN
> segmentation. The authors have asked for WG adoption.
>
>
>
> This begins a three week LSR Working Group Adoption Poll for “Using IS-IS
> Multi-Topology (MT) for Segment Routing based Virtual Transport Network” -
> draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF
> next week. Please register your support or objection on this list prior to
> the end of the adoption poll on 3/24/2020.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 6 Mar 2021 12:10:06 +0100

Hello,

I agree with Les that this draft may not be a fit for LSR WG.

Typically this type of effort (essentially describing use cases) is much
better to be put in slides and present on various operators forums.

That said I think perhaps we are indeed missing LROW WG (Local Routing
Operations WG) where just like in GROW WG where mainly (Global) BGP
operational aspects are discussed there could be good place to discuss
operational aspects of link state protocols deployment and use cases. In
fact perhaps it would also free some LSR bandwidth to really focus on
protocol extensions.

Thx,
R.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 6 Mar 2021 12:34:03 +0000

Hi Robert,

In my interpretation, you also think this document is useful to the operators.

This document does not introduce new encodings to IS-IS, while it provides information which was not covered explicitly in the specifications of the protocol encodings. For example, with the VTN mechanism, how traffic in different topologies are forwarded on a shared outgoing interface. There are also other points as mentioned in Chongfeng’s mail. Thus IMO it has its value as an informational LSR document.

A WG on IGP operation may be helpful. Before that happens, all the IGP stuff belongs to LSR:)

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Saturday, March 6, 2021 7:10 PM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Chongfeng Xie <[email-masked]>
Cc: [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Hello,

Typically this type of effort (essentially describing use cases) is much better to be put in slides and present on various operators forums.

That said I think perhaps we are indeed missing LROW WG (Local Routing Operations WG) where just like in GROW WG where mainly (Global) BGP operational aspects are discussed there could be good place to discuss operational aspects of link state protocols deployment and use cases. In fact perhaps it would also free some LSR bandwidth to really focus on protocol extensions.

Thx,
R.

On Thu, Mar 4, 2021 at 5:18 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Chongfeng –

Thanx.

   Les

From: Chongfeng Xie <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 04, 2021 5:04 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Hi， Les,

Best regards,
Chongfeng

   Les

Thanks,
Acee

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Mach Chen <[email-masked]>
Date: Sat, 6 Mar 2021 14:31:11 +0000

Hi,

I have read the draft, it describes how to leverage existing TLVs to implement SR VTN, it can be an useful informational document. Hence, I support the adoption.

Best regards,
Mach

Thanks,
Acee

---

From: Lizhenbin <[email-masked]>
Date: Sun, 7 Mar 2021 15:15:42 +0000

Hi All,
I support the adoption as the co-author. I believe MT can play an important role to build SR-based VTN and the current RFCs does not cover the topic. The draft will be an useful informational document.

Best Regards,
Zhenbin (Robin)

--------------------------------------------------
李振斌 Li Zhenbin
Mobile: +86-13651017745<tel:+86-13651017745>/+968-91797068
Email: [email-masked]<mailto:[email-masked]>
发件人：Acee Lindem (acee) <acee=[email-masked]>
收件人：lsr <[email-masked]>
时 间：2021-03-03 07:28:17
主 题：[Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 7 Mar 2021 16:33:57 +0100

> fact perhaps it would also free some LSR bandwidth to really focus on
+1

IGPs grew a zoo of horns and bells by now and no'one tells the operators
which spines are poisonous ;-)

--- tony

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 7 Mar 2021 18:28:55 -0500

Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.
MT instances has separate topology but not separate LSDB where MI Multi
instance RFC 6822 has a separate LSDB for resources isolation and I think
would be a better fit for VTN underlay provisioning.

MI

Thanks

Gyan

-- 

*Gyan Mishra*

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 8 Mar 2021 14:11:00 +0000

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the topology based computation, and MI can provide separate LSDBs at some additional cost (separate adjacencies, etc.). In this document, the resource of VTN mainly refers to the forwarding plane resources, thus MT is chosen as it can provide the required functionality with less overhead.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda <[email-masked]>
Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Chongfeng Xie <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT instances has separate topology but not separate LSDB where MI Multi instance RFC 6822 has a separate LSDB for resources isolation and I think would be a better fit for VTN underlay provisioning.

MI

Thanks

Gyan

On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

Robert ruminated:

+1

IGPs grew a zoo of horns and bells by now and no'one tells the operators which spines are poisonous ;-)

--- tony

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Tarek Saad <[email-masked]>
Date: Mon, 8 Mar 2021 14:43:42 +0000

Hi authors,

My understanding is the draft is proposing a separate MT topology (unique MT-ID) to identify a forwarding treatment to be enforced on a shared resource.
While this may work for limited number of MT topologies (i.e. forwarding treatments), as described in RF5120 there is overhead with creating/advertising and managing and running separate SPF for each of the MT topology. This will restrict the scalability of such approach (number of forwarding treatments to be realized) using this approach.

In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID (associated with the forwarding treatment) independent of the topology ID. This allows the # of forwarding treatmentst to be independent of the # of MT topologies that need to be managed by IGP; and hence, allow it to scale. Your feedback on this approach is welcome.

Regards,
Tarek

On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Gyan,

Hope this helps.

Best regards,
Jie

Dear Authors

MI

Thanks

Gyan

Robert ruminated:

+1

--- tony

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

Juniper Business Use Only

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 8 Mar 2021 09:52:08 -0500

Hi Jie

Response in-line

Thank you

Gyan

On Mon, Mar 8, 2021 at 9:11 AM Dongjie (Jimmy) <[email-masked]> wrote:

> As you mentioned, both MT and MI can provide separate topologies and the
> topology based computation, and MI can provide separate LSDBs at some
> additional cost (separate adjacencies, etc.). In this document, the
> resource of VTN mainly refers to the forwarding plane resources, thus MT is
> chosen as it can provide the required functionality with less overhead.
>
> Gyan> Makes sense.  As their are many ways to provide resource isolation a
> key point that this draft solution that it provides is an optimal resource
> isolation as that relates to forwarding plane isolation of resources thus
> from a TEAS Network slice perspective, MT was chosen purposely as the
> requirement is exclusively for forwarding plane FIB programming isolation
> and not both forwarding and control plane isolation super set provided by
> MI.  This maybe a good point to note as to why MT was chosen.  Also from an
> IGP perspective why ISIS is chosen over OSPF for VTN underlay resource
> provisioning as OSPF does not have a MT concept.
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Lsr [mailto:[email-masked]] *On Behalf Of *Gyan Mishra
> *Sent:* Monday, March 8, 2021 7:29 AM
> *To:* Tony Przygienda <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <ginsberg=[email-masked]>;
> Chongfeng Xie <[email-masked]>; Acee Lindem (acee) <
> [email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
> *Subject:* Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> *Silver Spring, MD
>
>
>
-- 

*Gyan Mishra*

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 8 Mar 2021 15:53:56 +0100

This argument seems fairly bogus to me. if you use IGP to flood some stuff
and then want the distributed computation stitch it together based on IGP
topology to get you a nexthop you end in computation which is something
like Bellman or Dijkstra or Boruvka. Unless you have some controller
distributing next-hops but then it's really PCE and not IGP AFAIS.

The difference in MI and MT is that MT carries the topology information
everywhere (you don't have to compute if you're not part of [simple check
on adjacencies] it but you still get stuff flooded). Some people like that
(manageability), some don't. IS does only flood to nodes connected in MI.

Operationally I learned ages ago that topologies disconnecting are some of
the most vexing scenarios and there MT is @ an advantage since partitioned
topology can be easily derived (and that's BTW why it's built that way with
strict adjacency negotiation). Reading the bestbar draft and looking @ e.g.
flex algo I am waiting to see how the "I cannot get there, why?" problems

On Mon, Mar 8, 2021 at 3:43 PM Tarek Saad <[email-masked]> wrote:

> Hi authors,
>
>
>
> My understanding is the draft is proposing a separate MT topology (unique
> MT-ID) to identify a forwarding treatment to be enforced on a shared
> resource.
>
> While this may work for limited number of MT topologies (i.e. forwarding
> treatments), as described in RF5120 there is overhead with
> creating/advertising and managing and running separate SPF for each of the
> MT topology. This will restrict the scalability of such approach (number of
> forwarding treatments to be realized) using this approach.
>
>
>
> In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an
> independent ID (associated with the forwarding treatment) independent of
> the topology ID. This allows the # of forwarding treatmentst to be
> independent of the # of MT topologies that need to be managed by IGP; and
> hence, allow it to scale. Your feedback on this approach is welcome.
>
>
>
> Regards,
>
> Tarek
>
>
>
>
>
> On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> Hi Gyan,
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>

---

From: Tarek Saad <[email-masked]>
Date: Mon, 8 Mar 2021 15:12:47 +0000

Hi Tony,

Just so we are on same page, I think you are agreeing on the overhead per MT (and even MI) that would be incurred using the approach proposed in I-D. draft-xie-lsr-isis-sr-vtn-mt to realize a forwarding treatment on a shared resource.

To you’re point on flex-algo producing disconnected topologies,  I-D.draft-bestbar-lsr-spring-sa is NOT adding any **new** considerations or a change that would impact the behavior for computing per prefix SID paths as described in I-D.draft-ietf-lsr-flex-algo. It is only proposing to associate a SID with a forwarding treatment.

Regards,
Tarek

On 3/8/21, 9:54 AM, "Tony Przygienda" <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

This argument seems fairly bogus to me. if you use IGP to flood some stuff and then want the distributed computation stitch it together based on IGP topology to get you a nexthop you end in computation which is something like Bellman or Dijkstra or Boruvka. Unless you have some controller distributing next-hops but then it's really PCE and not IGP AFAIS.

The difference in MI and MT is that MT carries the topology information everywhere (you don't have to compute if you're not part of [simple check on adjacencies] it but you still get stuff flooded). Some people like that (manageability), some don't. IS does only flood to nodes connected in MI.

Operationally I learned ages ago that topologies disconnecting are some of the most vexing scenarios and there MT is @ an advantage since partitioned topology can be easily derived (and that's BTW why it's built that way with strict adjacency negotiation). Reading the bestbar draft and looking @ e.g. flex algo I am waiting to see how the "I cannot get there, why?" problems

On Mon, Mar 8, 2021 at 3:43 PM Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:
Hi authors,

Regards,
Tarek

Hi Gyan,

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>>; Chongfeng Xie <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Dear Authors

MI
https://tools.ietf.org/html/rfc6822<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc6822__;!!NEt6yMaO-gk!W0I8TTnvfmnvtp4AbIlYuPMM8_M1XF91FAbQTNSjvXvd9Qq8qoW8C7H7OSh6fw$>

Thanks

Gyan

Robert ruminated:

+1

--- tony
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!W0I8TTnvfmnvtp4AbIlYuPMM8_M1XF91FAbQTNSjvXvd9Qq8qoW8C7HiECKYfg$>
--

[图像已被发件人删除。]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!W0I8TTnvfmnvtp4AbIlYuPMM8_M1XF91FAbQTNSjvXvd9Qq8qoW8C7FBSt5CLg$>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 8 Mar 2021 16:31:15 +0000

Hi Tarek,

Your understanding about the scalability implication of this MT based VTN mechanism is correct, this is also described in section “scalability considerations” of this draft. The value of this mechanism is that it reuses several existing TLVs together to provide the required function.

As for the mechanisms which can provide better scalability, you could refer to draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is introduced, and multiple VTNs can be associated with the same topology. Further discussion about that draft and its relationship with draft-bestbar-lsr-spring-sa could happen in a separate thread.

Best regards,
Jie

From: Tarek Saad [mailto:[email-masked]]
Sent: Monday, March 8, 2021 10:44 PM
To: Dongjie (Jimmy) <[email-masked]>; Gyan Mishra <[email-masked]>; Tony Przygienda <[email-masked]>
Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Chongfeng Xie <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Hi authors,

Regards,
Tarek

Hi Gyan,

Hope this helps.

Best regards,
Jie

Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>; Chongfeng Xie <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Dear Authors

MI

Thanks

Gyan

Robert ruminated:

+1

--- tony

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: <[email-masked]>
Date: Tue, 9 Mar 2021 10:52:00 +0800 (CST)

Hi Jie,

Now that you mention VTN-ID, I have to point out that the VTN-ID in draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in draft-peng-teas-network-slicing, just a new name. That can be seen from the evolution of the historical versions of the these two drafts.

See https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/

I'm glad to see that the idea in draft-peng-teas-network-slicing and draft-bestbar-spring-scalable-ns have been generously adopted by you.

Regards,

PSF

原始邮件

发件人：Dongjie(Jimmy)
收件人：Tarek Saad;Gyan Mishra;Tony Przygienda;
抄送人：Les Ginsberg (ginsberg);Chongfeng Xie;Acee Lindem (acee);Robert Raszuk;[email-masked];
日 期 ：2021年03月09日 00:31
主 题 ：Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Hi Tarek,

 

 

Best regards,

Jie

 

Hi authors,

 

 

Regards,

Tarek

 

On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" <[email-masked] on behalf of [email-masked]> wrote:

Hi Gyan,

 

 

Hope this helps.

Best regards,

Jie

 

Dear Authors 

 

MI

 

Thanks 

Gyan

 

Robert ruminated: 

 

+1

 

--- tony

--

Gyan Mishra

M 301 502-1347
 13101 Columbia Pike 
 Silver Spring, MD

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 9 Mar 2021 11:31:52 +0000

Hi,

Since this discussion is not related to the adoption poll for draft-xie-lsr-isis-sr-vtn-mt, please start a separate mail thread if you want to discuss other documents.

A brief reply:

In the current version or any previous version of draft-peng-teas-network-slicing, there is no scalability considerations, nor any mechanism to improve the scalability. While the VTN-ID in draft-dong-lsr-sr-for-enhanced-vpn was introduced for the scalability purpose one year ago. Thus I think your statement is totally wrong.

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 9, 2021 10:52 AM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Hi Jie,

Regards,

PSF

原始邮件
发件人：Dongjie(Jimmy)

Best regards,
Jie
 <null>
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>

Hi authors,

Regards,
Tarek

Hi Gyan,

Hope this helps.

Best regards,
Jie

Dear Authors

MI

Thanks

Gyan

Robert ruminated:

+1

--- tony

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 9 Mar 2021 11:36:35 +0000

Hi All,
I support the adoption of this document. It provides an useful mechanism to build SR based VTNs using existing IS-IS Multi-Topology instances to provide the network resources for each VTN.

Regards,

Giuseppe

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 12:28 AM
To: [email-masked]
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Thanks,
Acee

---

From: <[email-masked]>
Date: Tue, 9 Mar 2021 20:57:12 +0800 (CST)

Hi Jie and all,

I'm sorry to have digressed in the adoption on this informational draft-xie-lsr-isis-sr-vtn-mt-03. However, I think these enhanced-vpn related documents are closely related, although they are divided into multiple documents. So discussing the main document (draft-dong-lsr-sr-for-enhanced-vpn) doesn't conflict with this one.

For VTN-ID, I don't believe it is interpreted by you as for scalability purpose, which is very interesting. 

Here are two things:

1) The slice-based ID is introduced into the control plane and the forwarding plane, and the SID per slice is assigned and advertised. This is done by draft-peng.

2) Optimize scalability issues. For example, the forwarding behavior of prefix-SID per slice can be inherited from flex-algo. That is clearly described by draft-bestbar.

Please don't confuse the above two things, that is, you can't say that one thing becomes another just because we try to optimize one aspect of it.

Once the slice-based ID is introduced, it can be used to distinguish which slice the service belongs to, and that is not related with whether different slice can or not share the same topology.

Regards,

PSF

原始邮件

发件人：Dongjie(Jimmy)
收件人：彭少富10053815;
抄送人：[email-masked];[email-masked];[email-masked];[email-masked];ginsberg=[email-masked];[email-masked];[email-masked];[email-masked];
日 期 ：2021年03月09日 19:32
主 题 ：Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Hi,

 

A brief reply:

 

Best regards,

Jie

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
 Sent: Tuesday, March 9, 2021 10:52 AM
 To: Dongjie (Jimmy) <[email-masked]>
 Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; ginsberg=[email-masked]; [email-masked]; [email-masked]; [email-masked]
 Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

Hi Jie,

Regards,

PSF

原始邮件

发件人：Dongjie(Jimmy)

日 期 ：2021年03月09日 00:31

Hi Tarek,

 

 

Best regards,

Jie

 

Hi authors,

 

 

Regards,

Tarek

 

 

Hi Gyan,

 

 

Hope this helps.

Best regards,

Jie

 

Dear Authors 

 

MI

 

Thanks 

Gyan

 

Robert ruminated: 

 

+1

 

--- tony

--

Gyan Mishra

M 301 502-1347
 13101 Columbia Pike 
 Silver Spring, MD

---

From: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
Date: Thu, 11 Mar 2021 15:48:57 +0000

Hi, all

This document provides useful information about how existing IS-IS TLVs can be used together to deliver SR based VTN.
I support its adoption as an informational document.

Best regards,
Pang Ran

发件人： Acee Lindem (acee)<mailto:acee=[email-masked]>
发送时间： 2021-03-03 07:27
收件人： [email-masked]<mailto:[email-masked]>
主题： [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
This information draft describes how MT could be used for VTN segmentation. The authors have asked for WG adoption.

Thanks,
Acee

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 18 Mar 2021 08:55:06 +0000

Hi WG,

I support the adoption of this informational document.
The combination of IS-IS MT with TE extensions allows to build VTNs with customized topology and link attributes, and SR SIDs are used to steer traffic using the topologies and resources of each VTN.  This mechanism is clear and makes sense.

A small editor comment:
In section 1 introduction, it is mentioned that “Thus these properties require integration between the underlay and the overlay networks.” This sentence has some abruptness in the text . Does “underlay  network” mean network resource and “network overlay” mean network topology? More descriptions here may help in the following version.

Best
Xuesong

Thanks,
Acee

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 18 Mar 2021 19:47:59 +0800

Hi Xuesong,
 
Thanks for your support.
 
Regarding your comment about the overlay and underlay network, in this context the overlay refers to the VPN overlays which provide the service connectivity, and the underlay refers to the set of network topology and resources provided using VTNs. We could add some text in next version to make this clear.

Best regards，
Chenhao

发件人： Gengxuesong (Geng Xuesong)
发送时间： 2021-03-18 16:55
收件人： Acee Lindem (acee); [email-masked]
主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Hi WG,

A small editor comment:
 
Best
Xuesong

 
 
Thanks,
Acee

---

From: Takuya Miyasaka <[email-masked]>
Date: Fri, 19 Mar 2021 11:06:01 +0900

Hi all,

I support the adoption of this draft.

I reviewed this draft-xie-lsr-isis-sr-vtn-mt-03 and I think this draft 
describes a good use case which realizes VPN+ by using existing IS-IS 
extensions such as Multi-Topology, SR, and TE.

Thanks,
Takuya

On 2021/03/03 8:27, Acee Lindem (acee) wrote:
> This begins a three week LSR Working Group Adoption Poll for “Using 
> IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport 
> Network” - draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks 
> due to the IETF next week. Please register your support or objection 
> on this list prior to the end of the adoption poll on 3/24/2020.
>
> Thanks,
>
> Acee
>