Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

["[e-mail]" <[e-mail]>]

Gyan,
Thanks a lot for your review and comments. I agree with your summary of the basic concept in enhanced VPN framework draft. It is about the integration of overlay and a subset of underlay network topology and resource to provide the required service connectivity and performance assurance.
 
Source routing with current SR-MPLS or SRv6 is one important feature to achieve service path customization, and the color based matching of services to SR policy is useful in general. While performance assurance requires additional capability such as resource management and reservation on paths or virtual networks used for different services. I think existing SR mechanism needs to be enhanced to support resource awareness and provide resource guaranteed SR paths or virtual networks. These are described in draft-dong-spring-sr-enhanced-vpn. You can also review it if you like. 

Thanks.

Chongfeng
 


From: Gyan Mishra
Date: 2020-03-30 05:13
To: Tony Przygienda
CC: Aijun Wang; Dongjie (Jimmy); Les Ginsberg (ginsberg); Les Ginsberg (ginsberg); Peter Psenak; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

Hi Chongfeng & Jie 

I read through this draft which is referenced in the MT draft which is a good to read first to provide context as to what you are trying to accomplish with VPN+ idea.

https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05


In reading both documents the basic concept at a high level is that you are trying to provide a means of pinning overlay vpn service to underlay transport providing a form of isolation abstraction.

From a Spring Source routing standpoint source routing provided by segment routing flavors SR-MPLS and SRv6 provides the same vpn coloring and source routed traffic engineering via SR-TE for SR-MPLS and SRv6 native L3 vpn coloring with SRH traffic steering.  

So that coupling for IP SLA requirement of underlay pinning to overlay vpn via traffic steering coloring via candidate ERO paths to me seems to be satisfied by Segment Routing flavors.

Am I missing something?

Kind regards 

Gyan

https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05


On Sun, Mar 29, 2020 at 12:30 PM Tony Przygienda <[e-mail]> wrote:
As usual +1 Les  

Simply think what is the _L3 construct_ ISIS runs over which is easily identified as the same thing that adjacency runs over. If adjacency runs over each constituent of L2 bundel we don't have L2, we have L3 with confused naming. If adjacency runs over the L2 bundle the bundle is an L3 construct and hence MTID applies 

again, to keep things orthogonal (mostly on the encoding side but also underlying architecture)  I would derive 225 the same way we run 222. Otherwise we end up in funky places like "what happens if this bundle has more than one MTID and if it runs on no MT and a MTID" as well and what does it mean if it's missing and what if someone doesn't understand it and so on and so on. That stuff has been pretty well reviewed and thought out when it was done and all the tlv/subtlv discussions had then ...


--- tony

On Sun, Mar 29, 2020 at 8:57 AM Les Ginsberg (ginsberg) <[e-mail]> wrote:
Peter/Aijun -

We are in agreement.
I never said that an L2 Bundle member could/should be associated with a specific MTID.

It is the L3 adjacency that has the MTID association.
If we were going to support MTID in TLV 25 the correct place to put it would be as part of the " Parent L3 Neighbor Descriptor".

   Les


> -----Original Message-----
> From: Lsr <[e-mail]> On Behalf Of Aijun Wang
> Sent: Sunday, March 29, 2020 3:46 AM
> To: Peter Psenak <ppsenak=[e-mail]>
> Cc: [e-mail]; Dongjie (Jimmy) <[e-mail]>;
> [e-mail]; Les Ginsberg (ginsberg)
> <ginsberg=[e-mail]>; [e-mail]; Tony Przygienda
> <[e-mail]>
> 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
> <ppsenak=[e-mail]> 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 <[e-mail]> *On Behalf Of * Tony Przygienda
> >> *Sent:* Saturday, March 28, 2020 10:25 AM
> >> *To:* peng.shaofu@
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lsr
-- 
Gyan  Mishra
Network Engineering & Technology 
Verizon 
Silver Spring, MD 20904
Phone: [phone]
Email: [e-mail]