Hi Dongjie,
On 30/03/2020 05:13, Dongjie (Jimmy) wrote:
Hi Peter,
Thanks for your reply, please see inline with [Jie 3]:
-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Friday, March 27, 2020 11:45 PM
To: Dongjie (Jimmy) <jie.d...@huawei.com>; xie...@chinatelecom.cn; lsr
<lsr@ietf.org>
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
Virtual Transport Network
On 27/03/2020 16:32, Dongjie (Jimmy) wrote:
Hi Peter,
My question actually is: where does the TLV 222 column in the IANA registry
come from? As it is not specified in the IANA section of RFC 5120. It would be
helpful if you or anyone else could share some more information about this. If
normative specification of using TE attributes in TLV 222 could be found in an
RFC, we would add a reference to it and remove the editor's note in section 3.1
of this document.
I guess it came with RFC 5120.
[Jie 3]: Thanks, I saw Les provides some background about this. I will reply to
his mail about this part.
Some previous discussion are trimmed off...
[Jie] In this case, the L3 link is associated with the union of the MT-IDs
associated with its L2 member links.
For example, if a L3 link has three L2 member links, which are associated with
MT-x, MT-y and MT-z respectively, then the L3 link is associated with MT-x,
MT-y and MT-z.
I'm going to repeat myself here. You are misusing the MT-ID for something you
have defined. I don't think it is correct. L2 bundle link is NOT a topological
entity in ISIS, only the L3 link is. Associating L2 bundle link with a MT is
conceptually wrong.
If you wanted different bundle members to be part of different topologies the
obvious solution would be to enable L3 directly on the individual links rather
than combine them into one L3 Bundle interface.
[Jie2] I agree the usage of MT-ID is extended in this case. But if an L3 parent
link participates in multiple topologies, this could help to further identify
the member link which is only used for traffic belonging to a specific
topology. A similar attribute is the admin-group.
no, I don't agree. You can only associate MT-ID with a L3 link, not with
L2 link.
[Jie 3]: The MT-IDs are still associated with the L3 link, the purpose here is
to further associate each topology with a subset of resource of the L3 link.
IGP L2bundle is something near to what we need, the bundle member link could be
used to represent a subset of the resource of the L3 link. This may require
some extension or generalization to L2bundle, which is described in
draft-dong-lsr-sr-enhanced-vpn-03 and draft-zhu-lsr-sr-vtn-flexalgo.
sure, but MT is not the right mechanism.
[Jie2] Enabling L3 on each individual link is another option, while it
introduces the overhead which the L2 bundle mechanism tries to avoid.
well, if you want to use L3 constructs like MT-ID, it comes with an overhead. I
have expressed my concerns of the MT being used for what you are trying to use
it for in the past - and overhead was the main issue.
[Jie 3]: Since multiple topologies can be enabled on the same L3 link, it is
possible to reduce the overhead of multiple L3 connections. Following this,
what we need IMO is to find a suitable approach to advertise topology-specific
TE attributes for such a link.
as has been said multiple times, you can advertise TE attributes with L2
bundle member and no specification is required for that.
thanks,
Peter
Best regards,
Jie
thanks,
Peter
[Jie2] BTW, in the IANA section of the L2 bundle RFC 8668, it clearly specifies
which existing sub-TLVs are allowed in the newly defined TLV 25, and in which
existing TLVs the new sub-TLVs can be carried. Something similar documented in
an RFC for TLV 222 would be good enough to solve my question in the beginning
of this mail.
Best regards,
Jie
-----Original Message-----
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Wednesday, March 25, 2020 10:09 PM
To: xie...@chinatelecom.cn; lsr <lsr@ietf.org>
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
Routing based Virtual Transport Network
Hi Chongfeng,
what exactly is being standardized in this draft? I don't see anything.
thanks,
Peter
On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:
Hello, folks,
we have submitted a new draft of
https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
It is about Using IS-IS Multi-Topology (MT) for Segment Routing
based Virtual Transport Network. Enhanced VPN (VPN+) as defined
in I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN
service to support some applications's needs of enhanced
isolation and stringent performance requirements. VPN+ requries
integration between the overlay VPN and the underlay network. A
Virtual Transport Network
(VTN) is a virtual network which consists of a subset of the
network toplogy and network resources allocated from the underlay network.
A VTN could be used as the underlay for one or a group of VPN+ services.
This document describes a simplified mechanism to build the SR
based VTNs using IGP
multi- topology together with other well-defined IS-IS extensions.
Comments and suggestions are highly appreciated.
Chongfeng Xie
_______________________________________________
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
