Internet Engineering Task Force 94, 5 Nov 2015

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF94-MPLS-20151105-1740.webm

Description

MPLS meeting session at IETF94
2015/11/05 1740

A

Someone can account thank you, so this is a combined meeting between the T spotting group and the mpls working group. The theme is mostly young models and we will take a look at the overlap of young models between actually not so much an overlap in the model: s removal appt in the interest in the model fig we are focusing on. We have a thing for presentations and with that Lou.

B

So we have the usual note. Well, here we are are doing our normal audio and minute, taking Jabbar room and I tend to like etherpad I, don't know who do you have big notes? Okay and hopefully you're an etherpad? And if you're, not that's okay, we do have at least one remote participant are one of the co-chairs.

B

Also we have meat pepco, they stay in the box, use the mic and follow the normal rules of announce yourself. When you come to the night with that, so.

A

It's always amazes me, but then you say that you're always out of the box. You.

B

A

And so welcome, I think we jump straight to the first presentation and first up is camera.

A

And so replace, remember that we are trying to sort out the overlapping interests between the tubes working group so address that in your presentation, and that goes for all the presenters.

C

Hello, everyone good evening: I am Cameron reza from cisco systems. Actually, I'm going to present two drafts. First of them is version 0 0 and the other one is just an update from a previous draft. So first first draft is about yang data model for mpls base and static on the speed set of co-authors. You can see on this slide so in this document and this draft that people should right before the idea right before the idea, we are specifying to yang models and kills base and impulse static.

C

Lsp the base model is really really small. Portion of it is mostly ample static. Lsp, the m + base model serves as a base framework for configuring, and you know managing an M plus switching subsystem, where example, static, LSPs defines yang that are to configure and manage implicit, static, LSPs and impulse Empress static model of centos based model so going into a little bit more details of each of these, so MPLS based a model that we are defining is augmenting routing code model which is defined in that mode.

C

Routing configure internet draft, and but it has, is some additional data which is specific to emplace switching right now we don't have loss of data there, but this is just a framework to begin with and we will. We will enhance it as we go.

C

This base model augments routing instance, and it hence it allows mpls protocols that could augment this model to be running under a given routing instance or a wharf instance. Additional is this model also defines NPS interface list. There was some discussion earlier today on increased increase working group session on and Phyllis interface, so this kind of also we are slide to to present this. It also defines base MPLS label and some other base definitions that other models in mpls or even IP can can use from this model.

C

And last but not least, so we expect that other yang models in mpls, such as like ldp or sum sum of RS 3 PT, will augment this base as applicable and, where applicable, right so so, base 3 that we are defining in antillas base. Is it it is as follows. So so it ottomans routing routing instance, and it defines his own mpls leaf, underneath that instance, and any routing NE mpls protocol that wish to or that basically wants to run under routing instance, can augment this.

C

This mpls base tree a by defining its own tree under underneath the this mpls, an example where you have a later. Second part of my presentation is on ldp. So, for example, we will see an ldp that we are augmenting in phila space in our latest revision.

C

This model also defines instead tree, which is which is off or routing state while we are trying to. While we are trying to base you know, align with open config state, we are still keeping rockin state tree in our Empress base model until we get a consensus on a routing level that how are we going to represent state for a forgiving protocol?.

C

So in MPLS based interfaces, so what we are doing is that we are defining interface list under MPLS based model. Basically, what it means is that it defines an interface where you want to enable mpls. This does not mean you're enabling control pain. It just enables emptiness forwarding basically encapsulation and decap solution on a given interface, so the implants base is already defining defining a m+ based interface list.

C

As follows, so you have an MPLS and you have interface list and n routing protocol or an MPLS protocol that wants to use an MPLS that wants to enable an MPLS control plane procedures on a given interface can reference this interface, which is defined in n plus based interfaces. What I'm trying to highlight here is that if you have a protocol when you, when you reference this interface from mpls interfaces, forwarding is already enabled, because it's already an MPLS based interface list. This is assumption all you are doing by by referencing.

C

It is you're trying to either enable your control pain procedure on that interface or you're, trying to define some additional control, pain, related procedures. For that particular interface. In your in your in your protocol. Again, we will say for, for example, in ldp if it has to enable rdp discovery on an interface, so it will reference mpls interface from the list, assuming that mpls forwarding has already been able on that interface.

C

So we have couple pregnancies. Of course we are augmentin core routing data, core routing module, so you know if it is, any change happens on the routing instance whatever, so we will be impacted, but we are keeping an eye on this and other other other point that I made earlier was about the state tree. We have defined routing state for mpls, however, the you know models that want you to be aligning with mpls open, config, a style of state.

C

They may or may not use this this tree, but right now your model defines rounding state for mpls as well, so so next step for this is basically we are looking for some comment. This is the reminder, work that that is part of this draft. Probably I'll take comments on this before I move to second portion of this job, which is about mpls static, LSPs,.

C

Any comments, questions, suggestions.

B

Sorry being slow, so question is how much is left to align with the other models that you depend on and depend on. You I.

C

D

Mps business.

C

Not much left, however, there are some pending things like like state, so we have defined out in the state under mpls, but my understanding is that this is to being discussed that, whether we have all kind of state intended applied and drive under same tree of routing /, talking incest or we, we define drive estate under outta me state, /, routing, /, shouting stage, so I think that's the main main pending item that we have in / Olaf. Otherwise it has the basic framework.

C

It is very, very simple, really a work that we are doing, but not much. Okay,.

B

Given the set of overlapping authors, I'm, not too surprised at the answer, Thanks.

E

Okay, tarick's at I'm, a co-author of this, and in its current form the draft has both modules their base and static. My understanding is the working group chairs prefer that we split into two different drafts or, as not, is that not the girl.

A

I, don't think we have expressed a preference okay, but we told you to consider splitting them. So that's if you come back and say no, no, we want to straighten that would be disaster. We will accept that, but you need to consider splitting in two document. Okay,.

C

Thanks yeah, but but I guess I would probably at minimum. The draft name should reflect this right now. Drop name is ample static, dot yang, it should be imposed, a static thought yang, so people know n, plus, basically funny.

A

But that is a very, very easy comment to address. Let me make it work.

C

Group talk, yes, the reason we haven't changed it yet because we are still waiting on this decision. Any other comment all right so.

C

No I'm Lee static haven't done. This was just on all those rights.

C

Okay. So so, as in the same document, we have also implicitly LSP define so implicitly gillespie augments, its m+ base model that we just presented and it defines parameter a parameter related to and prosthetic LSP configurations and state. It follows the approach in terms of configuration and a pro and state. It follows approach that open config at state, open, open, config state model follows meaning that we define both configure intended configuration and applied applied state within the same tree. At this point, we don't see a need for a drive straight for a static LSPs get.

C

There are no protocol aspects of it, so only we have intended to state and apply to state in this model, and this model is consistent with IP static model which is currently being defined under routing a net, mod routing, routing, config or initial focus in IP, unicast and p2p LSPs from the earlier session on interacting working group about comments from on IP static and I to RS, and there are many static activities going on.

C

So we are keeping an eye and probably will also leverage some of the work done in other models to be using em too static. Alright, so so, basically, in employ static. We we defined it has only really building blocks we have in segments.

C

We have an operation that we perform an in segments and this out segment so in segments is basically for you look up for your faq, then you are probably an operation on that fact and as a result, you for your package and their different type by and you can forward your packet on single or multi path. So this model basically defines defines a set of definitions for in each segment operations and out segments. So this is pretty much somebody up, I, just SAT last minute that you have in segments.

C

So currently we have defined only to type of lockups IP prefix face, look up or or a label based, look up al roker label, and then you can perform based on this hook up. Then you can perform an operation to forward your packet and operations. Currently, is that you can do it in position? You can do so app, you can do part. That is a basic mpls. You can do there pop an impulse. The star really means that you can impose more than one label, and last but not least, is pop and look up.

C

You know, after all, these operations, eventually, of course, packet, gets forwarded using your outside meant definition, where you can have one or more paths, forwarding paths define yeah so right now we have two types of two types of far apart define, one is simple path and other is a set of paths.

C

List simple path is very basic, but this is following the approach, which is already in IP, static, defined in routing config model, and right now we have defined some path or abused, but not all, but this is just a revision 00, so I'll thing else escaped further.

C

Step 4 this is for is really to update this revision 00. We posted right before idea. There's some work to be done, especially explaining our at some subsection to explain over objects. We will do in the next revision right after ITF. We have to enhance our model beyond beard, same basic LSPs, maybe different type of next hops and enhanced pat attributes and leverage and basically a leverage and also you reuse.

C

Some of the definitions, which are already in other modules like a network, routing model or ITRs ribbon for model, and we are seeking comments from working group on this work. Any questions, government suggestions.

F

Login from Holly I think that this afternoon, in the RTG working group will truly talk about the network. Instances is the the the young model so because the stated I RSP user also the the entry in the networking instance. So how to synchronize this walk? Do you have any plan or have you see our next? No.

C

I just learned this in that last recession, so we probably meet as garter, and we will try to synchronize and also discussing, engage open, conflicting and this for this work.

F

When you use the what's the relationship with em casa, TV and the what's your plan, because I sing a state, your RSP easily to think about that I'm Charles TP, they also use some the state who the RSP so I'm, not sure. What's your plan on the I'm Charles TP, currently.

C

Plan is not to have amply sleepy as part of this work. Current focus is mostly IP, a unique ask and it will be LSPs. We may have P to mpls visitor on, but MPs TP is not currently in folk in our scope, but we can definitely visit this later on. Okay,.

F

So, even though I'm sure also designed here, we also know until now no plan on the I'm Charles TP, but.

C

For epistatic, yes, okay,.

E

So tired, San Francisco, so mpls-tp, we think it it deserves to be in its own draft or module rather than sticking stuff in less be static. That's something that we wanted to tackle, but we haven't yet. So that's our on our radar. It.

B

Is the question on the same topic or different topic.

F

No different, okay.

B

Then, before we leave that topic and.

F

B

Before we leave that topic, can you answer where it is mpls te fit in? Yes,.

C

So, that's probably what next phase of your work? Yes,.

E

We will be presenting where mpls te sets in this picture. Did you meet rsvp-te? That's an mpls d in general, okay, so yeah exactly so. We have. We have a presentation coming up and they.

B

Will be it about? What's the relationship between this workstation mpls te static, LSPs, there.

E

The parallel and they're not related, but they're, both augmenting and the mpls base. Okay, I.

B

Would have expected your answer on TP to the TP is a case of a static te LSP. But you didn't say that.

E

We think it convincingly rich set of features. You know running on number or none IP interfaces. So all this, which is not necessarily te well.

B

Since we have a talk on te, we should get there, but I think you're missing something because TP is a profile of te, not a digits.

E

An incision okay, all right.

D

David from I didn't have chance to read the draft, but I just want to know whether consider just global level space or per interface Globox. Yes,.

C

Its global level, a global, endless space we haven't highlight in this route, but will in the next edition, thanks for the comments?

C

Okay, if there are no more comments, I'll move to my second presentation.

C

Okay, so all this hung up so this is this is an update to an existing draft. This is on yang data model effort for lv, p and m ldp, which is almost going on for a year now, and this is multi-vendor effort you can see as the authors here, from cisco, alcatel, juniper ericsson, our way sienna, and there are also several other contributors which are not listed here, so just a quick background for everyone's benefit.

C

So we have a design team which is multi-vendor, and there are also a couple of operators that are initially join us had joined us from, for example, from orange or comcast.

C

We, if this was this meeting at this team, was formed during ipf 91 and since then we are meeting weekly to make progress, to define and basically make progress on this ma yang model for ldp /em, ldp division, 00 bus posted and presented in 98-92 in dallas, which covered basically p configuration and an RPC notification. Revision 01 was posted and presented at 1993 in Prague, which covered ml DP side of things, and this is revision.

C

2 was reported right before this IDF and in this revision, basically main work is to align with some of the open country comments as well, as also do some cleanup, so so main changes in revision to that that I'm, just giving update on our that now we are aligning with mpls base.

C

So now we are augmenting mpls, which is defined in mpls base, which which was presented earlier in my my presentation, and we also aligning with open config operational model where we are having same, we are doing intended configuration and applied configuration under under the same tree.

C

However, we still have our drive and state under routing state tree, so that Porsche that part of a state is not fully aligned with the open configured, but we are waiting for for little bit more consensus on rocking side before before we make this change and also we made some clarification in this revision from regarding the were fused a general model, so so, basically, basically so before in revision on television one, we were hanging off a routing instance as a routing protocol, because M plus base was not around so now.

C

We have ample space, so in our latest revision we are hanging off and mpls as an MPLS protocol, so we are still able to run in a routing instance for interface enabling under ldp. We did not modify our draft yet because this topic was still under discussion when we posted over drop. So we just closed in this topic almost during ITF. So in order a vision, ldp will be referencing mpls interface, to enable ldp on Olympic control, plane procedures on an in-place interface as defined an empty list under Atlas base model.

C

For operation I think I already mentioned this, so I'll just skip it, and this this model basically applies on both ldp nem ldp, so laters division has this open config alignment for both lv p and m ldp, which basically is as follows. So you can see you can see that for up for almost every leaf or set of leaf, we have config branch and we have a state branch under routing, so this is for intended configure.

C

This is for applied config, however overdrive the state that we drive in our protocol is hanging of rocking state tree and which we are working on. We have to find some of it, but we haven't added into a revision to yet. But right now we are hanging of routing states. So if a decision is to make Allstate under the same same tree, then then we'll just move our containers here, but right now, this is how its defined in all DB model right.

C

So there are couple of pending and issues on our side, not necessarily a on working that requires working group input. We have some LEP policies which are defined a little bit differently than their defining PGP. So we are trying to make do some alignment on this side, so ldp bgp, like policies, are more similar and we are. We have still took the to add, drive the state for ldp NM ldp or we have started this work. We have identified some attributes, but we have not updated this job yet so in the next revision.

C

Hopefully you will see all the drive to state for ldp, NM, ldp and hopefully by then does this. This work will be almost near to completion, so so next step on our side align further with ample space for interface, enabling for le P and M le P and extend this data model for dr least eight at and when we will be doing this. We already have been in discussion with an open convicting to work with us and be aligned with us.

C

And finally, we are seeking comments from you know broader community, on working group, especially from operators on the work which is already there. It's been almost a year, so this is revision. Third revision of the draft, and- and we feel that I think working as a multi-vendor team has been working for a year on config side of LD pml VPN has already identified, has already covered all the bases. Only remaining thing is a drive estate which we are working on. We think that this document is ready for working group adoption.

C

Of course, this is work in progress will will we will have to feel more things, but if others think that this is ready for working grow adoption, so I'd like to hear from cheers and the working group.

A

So now you put me into a problem and I'm one of the quarter. Yes, arms also believe as all the other co-authors, that this is very working group adoption, but I will have to leave the processing of testing of that to ross or your chip, so I will trigger that and I really. Okay, thank.

C

A

Actually, how much a wake? Yes! The second I have one one question that I'm a little bit worried about on the overall Jang modeling, for whatever area we're looking at hey I, think we can get tools so that you see how the things fit together and actually capture overlaps. That should be fairly easy. But what do we do about things where we actually left things out because they will never show up? So is that a completely manual process of actually given to look at?

A

We have four models they fit together like this, and there are certain overlaps and we take those away. But when we have gaps, how do we actually? How do we figure that out so.

C

You're simply you mean the gaps in or like in a specific areas. There is something somewhere.

A

With you haven't model in any model, and we think that there was model in that model up there and that we can.

C

I think anything which is common. She should go to empty space. For example, label was one thing common, so we didn't label in n plus base, there's no point in defining label and five more five different models, and also we were also debating that. Maybe you should define incoming local label different than outgoing label that should go to base interfaces was one common thing we defined in place based so probably I could see anything which doesn't fit anywhere. Boyd Glenn plays bass, and maybe that will that would make more sense to than empty spaces.

C

Is a document on its own going forward. I hope.

A

You're right and if you, if you're not you pay the dinner next time, we.

C

A

Okay, hi mansion.

G

So I himanshu from Siena I, actually don't have question on this. But I have a question on the static stuff for Lou because you talked about mpls de and this and the TP as a separate LSP, static, LSPs and I really want clarification. A.

B

Te and ter separate wealthy.

G

You mentioned te and then a TP being a profile or a subset of a te. So well just a just take a step back and the question is with respect to the TE: I mean what is a te static, LSP right. Is it like per ha behavior? The dips are TTL handling, LSP Marge penultimate hop pop or are we were? What are we talking about when we say te? As I know for TP, you can say: okay, you need to address.

G

You have to have a, maybe if its own number, then you have to have a mac address discovery. If it's ethernet, what method are you using and all that stuff, but it to get some sense of how we are distinguishing on the static LSPs?

G

So we can complete this properly.

B

That's also the TE part, I think, is in the next presentation right.

G

I did gonna.

B

Cover te, so it isn't. The question you're asking is about static te LSP is not static. Lsps the when I asked the question about the relationship before tarik said they're in parallel, so I'm happy to answer your question, but let's, if I, if it, but it's not answered by the next presentation, come ask it again and I'll give you the answer in that context, because this is the non te LSP discussion.

G

D

C

B

Right, even actually, all.

G

Right colloid I'll wait for the next presentation. The.

B

Difference between a are you suggesting that there's no difference between a te, static, LSP and a non te static. Lsp is that.

G

B

What you're asking I want.

G

To know exactly what do you need? What do you need to add on a static LSPs, a static LSP? Are we? Is it just that static LSP? Has the label switching construct and everything else is related to te. The EXP which setting the TTL the diff sir for her behavior, the LSP Marge penultimate hop up in all those tough is part.

B

Of this, from my standpoint, a t te LSP is in a generic thing and can cover any switching type that we support in GM pls and that te LSP could be signaled via things like RSVP, or it may not be signaled that maybe it's through a control plane such as you know, we've heard about some interesting piece, f uses that are completely supported today, but no one really uses things that way or it could be statically set up through a management protocol. So I, don't know that knows so.

A

Low and high manship I suggest that we actually let Tarek done, do his presentation first and then we return with.

G

Shepherd yeah no problem.

C

Any more questions.

H

B

Didn't have time to go search the dependencies, but bass mpls is that used by any of the t's modules, not.

E

Talking we need to enable an mpls on interfaces that are te traffic engineering, so then we have to reference the impaler space, okay. So for that matter, this.

B

Is a comment more to the mpls chairs that the eight authors, but once the documents are split out, it would be nice to see the base document become a working group document as rapidly as possible. Given that we have working group documents and tease that depend on.

A

So, okay, we can discuss the deep, so would that be a reason to split the base? Talk based part out as a separate document wrong. You.

B

Did notice a like race that right.

A

B

Yeah I think I think okay.

A

I have the reason, so we can go ahead and move on.

E

Hello, everyone, my name is tarick sad, and this is the we. We did a dry run of this presentation in the t's working group and I'm doing it again now I'm presenting an update on the two working group documents on the behalf of the of the team listed here.

E

So the presentation will contain updates of the work of the documents from the previous version, open issues and next steps.

E

The first update that we've done and this in the latest revision is, we did split the RSVP module into two pieces or two modules. One is the base RSVP and the other is the extended in the base. We, we are putting all the core functionality needed to operate this RSVP protocol and we're not allowing any feature checks in there. So that means that it has to be supported on all on all LS ours that support support rsvp-te.

E

This module will also contain features with minimal knobs, so as minimal as possible for the feature to work as minimal as having one leaf. That is to enable it the defaults for this. Enable leaf is left out, for you know, vendor implementation and the model that we're suggesting is not suggesting a default value. At the moment, the extended module will introduce the extra knobs to control the features, so all the extra knobs that an operator would need to attune the feature will be there.

E

It is optional and it's allowable to use the a feature check in there.

E

The second update we had is: we know that the PCE there is interest in the pc working group in developing a yang model for central controller and, if they've shown interest in reusing some of the groupings that we've defined already to maximize the reuse of the code, that or in the model that we were developing so in issue they pointed in our groupings, is that they are device dependent.

E

We are trying to solve this by offloading the device, dependent nodes or attributes on to a separate grouping, so that the PCE model or the central control controller model can use the groupings that we have defined.

E

The third update that we have is, we are introducing RSVP as a product as another protocol, just like ospf and in nine SAS and the other ones, and basically that we're argument in the the routing routing instance path.

E

With RSVP, which, where it where every attribute of RSVP, will hang off of that path and that will allow our GP to run in there in the indents. In the specific instance.

E

The fourth update we had is we try to address the ephemeral states, specifically the tunnels and LSPs in terms of tunnels. We have a container or list of tunnels that we define, they are read, write and we think that the ephemeral tunnels that are derived or protocol created should hang off of the state part of of the tree and the gotcha here or 11 and result of putting it under the state and being hanging off a read/write container. Is that operator is allowed to delete this direct state, and we think that is not.

E

That is acceptable at the moment. So it means that a PC created tunnel that is in there and still be deleted by the operator if they choose to the second update that we did.

E

The second update that we did for ephemeral, ESPYs as we we put them in a separate state read-only list, and these LSPs are the ones that are created by protocols like RSVP and they're, not hanging off of a read, write or configurable they're, not configurable. They derive by the protocol.

E

Open issues the first one we have we talked camron- did mention the MPLS interfaces, but we did to have an issue with RSVP interfaces.

E

There were multiple options that were considered if I want to enable RSVP on a specific interface, should I consider augmenting the routing interface list, so the list of interfaces that are in the routing module. If I do that, then because nls we can span multiple routing instances. We thought that that is too restrictive, so the incoming interface and outgoing interface can sit in two different routing instances. So that is one issue that we thought that might not solve the problem.

E

The second option that we considered is to augment the interfaces list and, as a result, we we will be exposing the RSVP attributes under all interface types. This is still can be limited by adding when checks on, for example, ip-enabled interfaces.

E

The third option is to have to augment the MPLS interfaces for mpls rsvp-te and that's an option. Just like mpls ldp will be doing. It will be augmenting or referencing the MPLS interfaces, but it doesn't solve the problem for different technologies and the last option that we consider it is to have the separate list of RSVP interfaces in our module and maintain that and we will be directly referencing. The ITF interface list in the character.

D

Yeah there's a fifth option: I, don't know which one you're here select.

B

But you could also augment the IP or ipv6.

D

Augmentations in 7277, as opposed to interfaces themselves, thank.

E

You yeah, but that is possible and we see there could be a small issue with that with specifically with rsvp-te that could run on none ip-enabled interfaces I the optical- and you know none on ip-enabled TP cases um but but I think it's a valid point. But.

D

There's no reason: I said that is a seal in them again. Is you mentioned using a when statement it as a constraint right.

E

H

E

H

Yeah comment on this with the recent update for the ITF rotting model, I think from AC they removed that list, so the first option is not available anymore.

E

D

Even before ac lindam, even before the last provision, you could not awed meant that list, because it was a leaf ref. It was just a ref, it wasn't to an actual interface, so you can't couldn't augment it anyway. Okay,.

E

So we could have asked.

H

You could, if you have a list of containers that would be okay but they've. Previously you have a loot list which is not possible.

D

E

The second issue that we have still open is how to enable mpls on rsvp-te mpls enabled interface.

E

You could do that in two steps and ask the operator to first enable mpls specifically on that interface and then add the RSVP attributes on that interface, and we call that a two-step approach.

E

The second way you could do it is do both in one chart and try to enable mpls an RSVP. At the same time, when you try to add.

C

E

Rsvp attribute, we did debate that and we we also got feedback from the operators, opie config team, and we think we converge to the first option of explicitly enabling mpls first and then adding any protocol control, plane, attributes after.

B

I didn't think it is going to work to have a data plane only interface that is controlled by RSVP, but doesn't have a control channel. How do you represent that? Yes,.

E

So this is specifically why we were leaning to option number four on on open issue number one. An option. Number four means that the data link and the control channel can be can be different, so your RSVP state can be sitting on an interview.

B

Enable at mpls or te on the interface but not RSVP, yes,.

E

B

E

This is the outer band case. There is the invent yeah.

B

I thought I heard inna talk about using disabling RSVP is basically an access met, access, control approach, so III guess I'm not quite sure how it's going to work out, but maybe that's a tattoo detailed level.

D

No perhaps my comment in the previous version was not about what it was. It was about actually wanting to have explicit yeah, enabling you look a little closer, so we actually want to enable explicitly mpls on an interface not have it. You know as a side effect of having enabled RSVP right.

D

And yeah you know, and and this is opposed to what you had commented- the other time where you know which I really liked having mpls be and implicitly enabled when you enable a protocol, but the operational feedback was that no, we do want that explicit, not because it's a method to control what traffic you alone interface is coming too.

D

A

E

So on this slide, I'm showing the relationship between the structure of the different module and hope that it will help clear up some confusion. This is what we came up and this is what we're executing I came up with. So basically we have a RSVP module and and extend a base and extended version of RSVP.

E

We have a te module traffic engineering module and then we have RSVP traffic engineering and then an MPLS rsvp-te module I mean so there are modules that we have not worked out yet and we're targeting to address. One of them is spring or segment routing traffic engineering and specifically the mpls data plane of srt or segment routing the mpls static that was presented earlier. My colleague here is augmenting the base and it appears here.

E

We think that mpls-tp will be parallel to this, but I think we need I, need you, no more clarification, maybe or the chairs after her or maybe with low parallel.

B

E

Parallel to mpls static, so it will be augmenting mpls face and in your thinking more of a traffic engineering, yeah yeah.

B

We've always talked about TP as being a form.

E

Of engine traffic.

B

Engineering, so it will sort of seem to fit their. The part that you don't have here showing shown is the relationship with different switching types or different data, plane technologies and how that fits in. You have that elsewhere, but not going.

E

To some ways on the slide but but I agree with you that the different technologies will fit in here. So we have. We are showing mpls because we are in mpls working group yeah. But it's.

B

Not RSVP, it's not about our SUV. It's about te! Yes,.

E

So something is, we are signaling mpls s, mpls de lspci RSVP at the moment, and this is why.

B

We're ending up right right, but there are te LSP s which are non packet and then are not signaled yeah.

E

Are the static on the space they could be? Okay, so can we use the static model for that? Okay? That is the thing that right.

B

Then really just a te at base te LSP should be a GM pls, LSP, meaning or, alternatively, is- is an LSP that can handle any arbitrary, switching height. That.

D

B

And packet is certainly one of them and for packet he needs to be one of those for certain things. There's no difference in terms of TP and a packet te other than perhaps how its control right.

E

I think it's about a point, but we need to you know, rethink it how it will fit in the election. I.

B

Think parallel is just fine, but I think it fits off of IETF te. Okay,.

E

D

B

It's anyone who is welcome to disagree.

E

F

Roving hobby, a pro we are slice previously I. Regarding the odd yeah, they saw my comment sealed at a similar, I'm, not sure I'm, similar as the bloopers or not. For my point, we owe the state either from my pocket. Wheel. User in factories also has some this. The attribute of the traffic engineering as the attribute of the traffic engineering is a noted directly to derive the from the piece I'm sure Sofia model because of the state higa RSP. You can configure the transit RSP without thinking about the route, so I think that's, that's.

F

A user also has some this. The seminar attributed like the traffic engineering, in fact that we can use as they take the air speed we explained at. We implemented the explicit the past. Okay.

E

Your comment is with regards to TP right, no.

F

You, a human inquiry, concluded the stated our aesthetic Alice fees.

E

So to answer your question: Robin so did the traffic engineering contains more? You know, attributes in terms of constraints on the path computation at the at the ingress. Now, how do you signal the path? That's a different thing, but we don't think static. Lsps will need constraints or path computation.

E

You know model in there. It's it's everything statically driven, and this is why I'm saying static will not augment the TE part yeah.

F

My comments are you there static, RSP to some extent, this human seminar at the SRT user just implement the explicit the past. That's the traffic engineer in the attribute, so.

E

Again with us RTE, there are constraints on path, computation that you have to run, see SPF and all that produce a stack and we think static. Lsb does not need to do any computation. Ok,.

F

So I would later mattias kasha I.

A

Mention you're guilty to return to the previous question. Our yeah.

G

A

Like two minutes, because family regret soo phone to do his presentation: okay, okay,.

G

I'll, wait till you finish.

D

A

No juming estas loco a knob.

G

My comment was that it seems that the ITF mpls static yang should hang off of IT ften. You know not at the base but off of RTE yang, so you can get some of the t, specific parameters in the static LSPs right to have a per ha behavior and all that stuff.

G

E

I would like to discuss more to understand why you want to inherit traffic engineering attributes into static, keep.

B

In mind, static is for what we don't really think of as LBP based LSPs also.

F

B

I mean that's where I'm.

G

Not necess the static LSP.

B

You want to say all LSPs, RTE LSPs.

G

hmm Well, no stack all I'm saying is that this LSB has a tee specific characteristics and hence it should be under the tea yang. Otherwise we're. Where would you get that you will have to do it on the under static itself? It would be duplicated.

A

I'm not sure I think this is a bit detail and that we can't really take this discussion here. It was a typical thing to take to the mailing list and gay.

G

I will love will discuss our way. Thank you. So.

A

So phone, it's your, are you I'm.

E

Done the last the last night I had this the next steps, so we didn't want to converge on the open issues and the next address the segment routing traffic engineering module. That's.

D

A

H

Hi, this is Jeff only Oh from medicine reporting, the status of teeth, parte young model on behalf the design team. So, since last ittf session, we have done few things, here's a summary what we have done. We have a completed alignment with the advanced network, generic network topology model. We have added a few features, including support for matta access links, inter-domain links, ICD recovery status and we also have moved the skyrim parameters into a separate model.

H

So what we have down with the eye to eye on generic network to party model is that we augment that generic to party model, mostly what we need to do with us to the key mappings. The generic network model consists of four networks, links, know and the TP combination points. So what we have done with my pal network authority to the network entity here, then we, my power, Peter, podium, IDs, a pride ID clarity, theater part ID into the primary key of the network. Id.

H

Then we, my party in order ID to the general generic network, topology node ID.

H

We keep all not idea. That's alternate key. So with deal similar things to the TP ID, so we have our own TTP ID and then you're the generic models, the TP ID at the primary key. So then we have a key link which is a inherited from the generic model. We don't need to do anything here because they already have the primary key at the link, ID and also they also have alternate key to provide the source destination.

H

For the features we added support for multi-axis links, so what we have done with the ID attribute to the link to indicate it as a romantic access link at the system will generate a grid, only ship pseudo node with the flag saying that this is a multi access. Dr we added support for inter domain links, so under lyne contribute we added the configuration container so which is a bit less tau, which means this is a intradermally.

H

So we on the note we added a flag to indicate than Tommen ad, so so that so we know which domain is not belongs to for the ICD. We added a list of adjustment capabilities so so that we can have the information about the upper layer scale switching capability, so we also added support for the recovery status, which can be protection status of recovery, restoration status. Then we moved the scheduling parameters into a separate model.

H

This will be a separate document later then we have our to-do list, our github. So will we have received some comments and they will complete the app those comments and the updated document and what we are yeah. We welcome further comments. That's it.

A

Okay, any questions we are a little bit over time. So, if you have questions be crisp about.

A

Okay, so thank you and thank you for joining our meetings, see you next year in South America. Thank you and.

B

Thank you to the mpls chairs and working room for hosting teas.

A

Actually I will send out the mail on those mailing list and ask if this is a way of saying we want to do next time, also a little bit ahead of the meeting and not doing it during the event planning on the meeting.

D