-----Original Message-----
From: Lsr <[email protected]> On Behalf Of Aijun Wang
Sent: Sunday, March 29, 2020 3:46 AM
To: Peter Psenak <[email protected]>
Cc: [email protected]; Dongjie (Jimmy) <[email protected]>;
[email protected]; Les Ginsberg (ginsberg)
<[email protected]>; [email protected]; Tony Przygienda
<[email protected]>
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing
basedVirtual Transport Network
I have the same consideration as Peter.
Aijun Wang
China Telecom
On Mar 29, 2020, at 17:10, Peter Psenak
<[email protected]> wrote:
Hi Les,
On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote:
Tony –
There are a few misunderstandings in your post.
Let me try to correct them.
RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of
TLVs 22,23,141,222,223.
Conceptually, it could have been defined as a sub-TLV, but because of the
limited length of a TLV in IS-IS (255 octets) and the likelihood that
advertising
L2Bundle member attributes would consume a significant amount of space,
we decided to use a new top-level TLV which references the associated L3
adjacency advertised in TLV 22. This means TLV22 advertisements are not
impacted by the presence of TLV 25. In particular, the use of TLV 25 does not
lead to multiple TLV 22 advertisements for the same adjacency, which we
thought was a desirable outcome.
The equivalent OSPF draft (https://tools.ietf.org/html/draft-ketant-lsr-
ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 bit
length for TLVs it does not face the same encoding issues.
I fully agree with you that an L2 bundle is a Layer 3 construct – and as such
can be associated with any Layer 3 MTID in theory. However, when writing
RFC 8668 we did not consider that there was a use case for topology specific
link attributes. The current encoding does not support MTID.
RFC 8668 defines a TLV to advertise attributes of the individual L2 link
members. While the TLV itself can be considered as L3 construct (and have
MT associated with it), the individual L2 Bundle Member Links inside this TLV
are not L3 constructs IMHO and should never have a MTID associated with
them. The ask here is to advertise different MTID for each individual L2
bundle member link.
MTID is used to construct a topology. I do not see how a L2 bundle link
member would ever become part of the L3 topology.
my 2c,
Peter
At this point, if we needed to extend RFC 8668 to support MTID we would
need to allocate an additional TLV code point that included MTID – similar to
the distinction between TLV 22 and TLV 222.
HTH
Les
*From:* Lsr <[email protected]> *On Behalf Of * Tony Przygienda
*Sent:* Saturday, March 28, 2020 10:25 AM
*To:* peng.shaofu@
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
