Wednesday, July 22, 2026 · Vienna, Austria
Datatracker · Materials · Notes · Zulip
Room: Grand Klimt Hall 2
| Video · Audio · Onsite · ICS
| Time Zone Converter
Presenter: Chairs
Presenter: Chairs
Draft: draft-ietf-teas-actn-poi-assurance-04
Presenter: Daniel King
[Italo Busi] I support the change of scope.
In ACTN POI Applicability we were able to build a
multi-layer/multi-domain network view and path setup because TE Topology
(RFC8795) and TE tunnel models were carefully designed to create
topology view and paths across multiple layers and multiple domains:
integrating two layers or two domains is exactly the same.
For ACTN POI Assurance we are discovering that this is not that simple,
and that most of the complexity is in how to do SLA assurance across two
packet domains, which is not the main focus of this document.
We can threfore focus on correlating an issue in the optical domain with
an issue in the packet domain.
The issue of understanding where the issue is in a multi-domain packet
entwork may be independent from the fact that there is an underlay
optical network or not.
[Daniel King] So to summarize we focues on the vertical layering
rather than on the horizontal layering.
[Oscar Gonzalez de Dios (as a chair)] If you want to ask the WG
whether it is relevant to reduce teh scope, it would be good just to
clarify what you are meaning by domain: if it is an IGP domain or it is
a single controller and you do not care if there are multiple areas.
[Daniel King] Yes, we will clarify this and move this discussion to
the list as well since there are people who may have an opinion and are
not in the room right now.
So we will not make any change to the document, and publish a new
document, until we get a consistent support.
[Oscar Gonzalez de Dios (as a chair)] Just clarify what you mean in
the scope.
[Italo Busi] I disovered working with Daniel on this slide that you
are right, the domain term means different things to different people.
In the ACTN POI Applicability we have defined the domain as the network
which is under the control of a single PNC. So the idea is to have only
one packet PNC that controls the packet network, which can be single or
multi area (it does not matter), and one optical PNC that controls the
optical network.
[Daniel King] Yes, it is when you start having multiple controllers
that the things start to get really complex.
[Vishnu Pavan Beeram] It is primary the inter-operator inter-MDSC. It
would be useful if you can formulate that in the scoping discussion.
[Daniel King] This deviates slightly from the ACTN POI Applicability
document because although we use the same topology model, it is now
reduced. For this document the plan is to scope it very early in the
document so it is clear.
[Swamynathan Balasundaram] Is this simplification only for the packet
domain or also for the optical domain?
[Daniel King] It is for the optical domain as well.
[Swamynathan Balasundaram] I can understand the complexity in the
packet domain but I do not know what is the complexity for the optical
domain.
[Daniel King] Nothing changes in the optical layer so we still have
multiple optical PNCs so we just have a single packet PNC.
[Swamynathan Balasundaram] So MDSC, one packet PNC and multiple
optical PNCs.
[Italo Busi] I can undertsand the argument but in the current ACTN POI
Applicability we are assuming one optical PNC for each packet PNC.
We have taken out of the scope the multi-domain optical cases because
there were some feedbacks that usually there is a one-to-one
relationship between optical and IP domains.
So I do not know if we want to go over multiple (optical PNCs)
[Daniel King] It is more likely that we would have multiple optical
PNCs that provide connectivity to the same packet domain, because it
could be a three nodes hop
[Italo Busi] Okay, so that is going to be a bigger change with respect
to ACTN POI Applicability so we need further discussion
[Daniel King] Basically the complexity comes when you are starting to
get multiple sources of information from different packet PNCs
[Italo Busi] Yes, but the current ACTN POI Applicability assumes that
one optical domain is providing connectivity to one packet domain so it
depends on how much we want to deviate from that assumption
[Daniel King] That's the main contention issue that requires extensive
discussion
Draft: draft-ietf-teas-ns-ip-mpls-08
Presenter: Tarek Saad
[Jie Dong] Slide about fallback: it says the indicator can optionally
be signalled within the NRP Selector itself.
Just want to clarify whether this should be part of the Selector: if we
are using a dedicated Selector ID, is this information carried as part
of the Selector ID or it is within the encoding of the Selecrtor ID,
together with the Selector ID but separately.
[Tarek Saad] In the document we did not define any encoding for any
data plane. We have kept it agnostic of the data plane encoding.
Nevertheless there was a poll done in TEAS WG and it was deemed
interesting to the WG to carry this additional information inside the
packet, so as part of the NRP Selector ID itself.
I think I have put the term "signalled" but I have meant to say it is
carried in the selector itself.
It is not signalled in the control plane. It is carried in the packet
the instruction of wheter to drop or not, but we did not define any
encoding in the document about how we carry (this information) in the
packet.
[Jie Dong] So TEAS WG will not give limitations of where this piece of
information will be encoded in the NRP selector or selector ID. Is that
correct?
[Tarek Saad] That's exactly what I am trying to say.
We did not define any specific encoding to where do we put this and how
it is encoded in the packet.
We left this exercise to the specific data plane that is going to define
the NRP selector.
[Jie Dong] Ok, thank you.
Another quick question: I just went through the draft quickly and it
seems there are some examples which are specific to the MPLS encoding,
like the override of the service label as NRP selector.
Do we need to go to that specific in this draft or that will be left to
the MPLS WG?
[Tarek Saad] The idea was to have an example and to be a meaningful
example and we chose MPLS for the example. I cannot abstract it and
still call it an example.
[Vishnu Pavan Beeram] It is an appendix as an example. If you think
another set of examples need to be added, please feel free to send some
text.
[Jie Dong (from Zulip)] Just checked draft-ietf-teas-ns-ip-mpls-09, in
section 5.1.1, there is one bullet on "Overloaded service identifier as
NRP Selector", and VPN identfier is mentioned as an example, then a
digaram of MPLS label stack is given. It would be good to mention that
MPLS data plane is used as an example here.
Draft: draft-ietf-teas-5g-network-slice-application-07
Presenter: Luis M. Contreras
[Luis M. Contreras] A question for the chairs: once we have a stable
version, would it be convenient to generate a new liaison statement or
reply back to the previous one so that 3GPP can confirm that everything
is ok or not, or we can go along.
This is an open question maybe to be answered in September when we have
the new version.
[Vishnu Pavan Beeram (as chair)] A reply seems appropriate but we will
work with our liaison manager and figure out an appropriate way of
sending it.
Draft: draft-ietf-teas-ns-models-applicability-02
Presenter: Luis M. Contreras
[Luis M. Contreras] There was some discussion about whether this
document can be moved to ONSEN WG in some point of time. Maybe somthing
we will have on the horizon for a new home.
For now we will keep working here but just to refresh this to the
audience.
[Vishnu Pavan Beeram (as chair)] So far we just continue progressing
the documents that we have.
We have not had any formal discussion with ONSEN WG about that.
[Oscar Gonzalez de Dios] Tomorrow there will be the session for ONSEN
WG so this is one of the thing that can be clarified also.
Draft: draft-miyatoch-teas-actn-inter-operator-extension-00
Presenter: Takuya Miyasaka
[Daniel King] Really timely because this topic has come up on our ACTN
POI Assurance calls.
I am wondering whether this is a solvable problem because the Mplify
Alliance, formely known as MEF Forum, have their Lifecycle Service
Orchestration (LSO), the have a sort of LEGATO with a whole set of APIs
that were supposed to allow coordination, sort of setup and tear down of
resources, across providers.
Has that project failed for your perspective or it does not actually
have the capabilities that you need?
[Takuya Miyasaka] We are now studying to a gap analysis for the Mplify
LSO and we will include this kind of gap analysis in the next version of
this draft.
[Dhruv Dhody] When we were discussing the original CNC design, this
idea of multiple operators come in.
We made the assumption that the MDSC of one operator could act like a
CNC for another operator and this just fits into the (existing ACTN)
architecture so we do not really need to define something else.
But, it seems that you have use cases where you are thinking that it is
not a CNC relationship. Is this that the two operators are not really
trusting each other, they have some kind of cooperation agreement which
is not like a customer-operator relationship but like two operators.
But what is the boundary between when it is a multi-domain versus two
operators who are just deciding to work well with each other? From a
technical architecture point of view?
I think those things we need to break down a little bit before we jump
to how this interface will look like.
[Daniele Ceccarelli] I share a little bit the view of Daniel that this
is probably not exactly work for IETF but if we think it is good, we can
try to work on that.
What I was trying to better understand is the applicability of this
document because as an example you are bringing an operator in the data
center and an operator in the transport network, but do we have MDSCs in
the data center?
Are operators deplying MDSCs in data centers? That's something I am not
seeing but I can be wrong.
Are there other examples where do you think this can be applicable?
Because this example is not something we can see frequently in networks.
[Takuya Miyasaka] Please discuss later offline.
[Italo Busi] Dhruv has already made more or less my comment.
Maybe, you can take a look at Figure 10 of RFC8453 which describes the
scenario where the MDSC (of one operator) can act like a CNC (toward the
MDSC of another operator) and we can discuss why this scenario is not
applicable to this use case.
Room: Grand Park Hall 1
| Video · Audio · Onsite · ICS
| Time Zone Converter
Draft: draft-many-teas-power-steering-01
Presenter: Ron Bonica
[Oscar Gonzalez de Dios] Regarding the metrics and the power savings,
we need to have an alignment with the Green WG that is where information
about power is being defined.
So we need not just to assume that we are consistent, so please keep a
coordination between the Green WG and this work.
[Tony Li] We had this discussion with Green WG and we already have
agreement with them.
We do not have exact overlapping data because our data space
requirements are much more stringent.
They are doing a YANG data model while we are trying to embed as few
bits as possible in the IGP.
So we agreed we have the right information on both locations.
We think we coordinated already.
[Oscar Gonzalez de Dios] Okay, so please keep this coordination.
[Zafar Ali] I did send you a comment yesterday. I am overall
questioning a few things, not everything, and I do not think you are
answering that question.
First thing is when you do such a low level of modelling, then you have
to be able to make sure that the power value that that you carry is
correct.
So the question is how do you have to do that level of bordering or the
attribute that gives you the best bang for the buck is the interface
level and we do some simplification around those lines and how it
connects with the true data model.
My concern goes back to your own statement in LSR WG that you did not
realize that the power in sleeping bandwidth is not zero, which means
that I can that when I have to implement it, I will have difficulty: for
this power group that much power, for that, that much power.
It is maybe too fine grained of modeling and maybe the attribute is
really a laser or interface level that you want to keep it at level and
not to go in a lower friend right here.
This is what I meant when I say the data model has to be correct, so
people can implement it easily, can deploy it easily.
[Ron Bonica] When we first started the project, every piece of
hardware that we looked at had a sleeping power consumption of zero.
Carlos Pignitaro brought to our attention that there are other pieces of
hardware in the world that might not.
So we changed the model. We did not have to change too much, all we had
to change is the name of a variable, changing it from absolute power
consumption to potential power saving.
Where do you get this information? There are two possible sources.
First, an hardware component may make it accessible through a
programmatic interface. There might be a way to ask the hardware how
much power it consumes when sleeping and when awake. We do not know a
piece of hardware that does that.
Another way, is to do it by configuration. The hardware vendor publishes
this in a spec sheet. You enter it in your own CLI, or however you
configure your router, and you have it.
But in eiher case, you are pretty sure that it is correct.
We do not specify how you get the information, but if you configured it,
it woudl better be correct.
[Zafar Ali] I think what is the best level to work with maybe the
laser interface level or that kind of simplification can help because
otherwise, if you keep it too generic, some people will say oh my god is
this power supply or that component and people do not even know what is
the actual power when it actually carrying traffic versus not carrying
traffic.
There is a lot of room for simplification here.
Poll: Does the WG think that Power-aware traffic Engineering is a
topic of interesest for TEAS WG?
Poll result: 28 yes, 2 no, 5 no opinion
[Oscar Gonzalez de Dios (as chair)] I see a significant number of Yes
with a couple of No.
If those that voted Not want to say why do you think this is not a place
to do power-aware traffic engineering please stand up, otherwise send it
also to the list. But it is interesting to understand why you think
there it not interesting (the topic itself).
So we have pretty much amount of people going for, then I would like to
poll if this particular document, the one that we have just seen, is a
good starting point to work within this WG.
There would be other strategies, or other ways to do traffic engineering
but, at least, is this particular document a good starting point?
Poll: Is this document a good starting point for discussing
power-aware traffic Engineering?
Poll result: 18 yes, 3 no, 16 no opinion
[Oscar Gonzalez de Dios (as chair)] The same number of No we have seen
before remains.
If one think that the topic is of interest for the WG but this document
might not be the best, if you can give the reasons. So please either
send it to the list or stand up now to say why you think so.
It is more or less half of the people that said that power-aware traffic
engineering is a good place in TEAS WG, support this document.
We will continue the adoption on the list in any case.
Draft: draft-saad-teas-rsvpte-ip-tunnels-03
Presenter: Vishnu Pavan Beeram
[Kireeti Kompella] Thanks to you and your co-authors for the document.
I will be referring to this in the MPTE document because we want to
support both MPLS and IP data plane and the current way of doing IP data
plane for MTPE is a bit cumbersome.
This is a much better solution but it requires the EAB.
So we will leave both options in.
From the point of view of using this solution, I will just point to your
document and in the MPTE document I will say how to use the other
method.
[Zafar Ali] I had the same comment in MPLS WG that you mentioned when
you presented this.
This comment is specific to SRv6 and SR-MPLS and not for others.
SR is a stateless fabric and it is programmed by IGP in a distributed
fashion regardless of the user scalability and all those attributes SR
come from.
That is part of the SR architecture and what your are doing is you are
introducing state in the fabric through RSVP signalling.
The programming is already done, but when it was done for MPLS and it
was for programming label switched paths.
There is a large deviation from the SR architecture here and if you want
to go that you have to modify the architecture document, the base
architecture.
[Vishnu Pavan Beeram] We can have a discussion in SPRING WG about
this, about whether this is actually violating anything in the SR
architecture or not.
At this point, all I'm saying is I'm trying to bring in bandwidth
engineering toolkit to a forwarding plane that's either native IPv4,
IPv6 or SRv6, but I note your comment and we can have a larger
discussion about any violations that are happening because of what is
being advocated here.
[Lou Berger] Have you thought about operating sort of tunnelless? You
are doing IP and IP, why?
Because you are already going to have to program the data plane doing
non-shortest path forwarding for the endpoint. So what is the real value
of doing IP and IP?
[Vishnu Pavan Beeram] So you're saying, why you cannot use the
address?
[Lou Berger] You are going to do an n-tuple matching anyway, right? It
is not going to be just on destination.
[Vishnu Pavan Beeram] The issue is with the fallback. So, if something
goes wrong with what gets programmed, you do not want some other
protocol using the same route and creating a route for that protocol and
taking over, causing forwarding loops and things like that.
Having a private address used specifically just like a label will ensure
the loop-free semantics that you get with MPLS are kind of mimicked.
That was the high-level thinking.
[Lou Berger] That's a reasonable answer.
[Lou Berger] The problem comes up is: if you want to have multiple
tunnels that end up at the same place, you are still going to have to do
the n-touple matching.
I do not think you have covered that in the document but I might have
missed it.
[Vishnu Pavan Beeram] I think it's covered.
[Lou Berger] Okay, I don't think I saw that.
[Lou Berger] The other thing is that it is interesting to bring in
SRv6 here, because you now have a new document.
At the time, I think when you first presented this, there wasn't the the
RSVP/SR document, right? That's new.
So why not cover all of SR in one place?
[Vishnu Pavan Beeram] This still is an IP-TE document, so it will
cover IPv4 and IPv6. SRv6 is another IP flavor.
[Lou Berger] Well, it doesn't really matter. The tunnel one was really
the main question.
[Boris Khasanov (from Zulip)] Looks that this work correlated a bit
with PCECC architecture
Drafts: draft-kompella-teas-mpte-03, draft-kbr-teas-mptersvp-04, and
draft-beeram-teas-yang-mpted-04
Presenter: Kireeti Kompella
Draft: draft-stone-spring-mpte-sr-02
Presenter: Andrew Stone
[Kireeti Kompella] Two things.
One is thank you for the draft because it actually captures the spirit
of MPTE: what you are doing with the binding SID and the junction SID is
load balancing at every node, not just at the ingress.
[Andrew Stone] At every note where you have a split.
[Kireeti Kompella] The second thing is, your comment about hierarchy
seems to fit very well with multi-ingress, so I don't know if you could
just parlay that into multi-ingress.
[Andrew Stone] The draft for multi ingress actually comments on that.
I kind of skipped over some of the nitty-gritty details that are really
segment routing specific, but in the SR policy architecture, the SR
policy is color, right? That's your intent: that is kind of your
implicit steering of service traffic.
So the draft actually describes that, that SR policy on ingress, that
color value, is actually unique to your DAG color that you want to use.
That gives you two properties.
One, it helps them make before break global optimization.
The other is: if you have multiple ingress, steering on the DAG can be
reused. So as long as your egress is common, your ingresses can leverage
multiple DAGs.
So in this diagram (slide 5), for example, X might be an ingress PE in a
simple area topology X might be an ingress PE, Y may be a different
ingress PE, A is a border router that they both have, and that's your
entry point into the DAG. And by border I mean like a ring border or
something, right? So as long as they're going to the same destination,
those DAG reuse.
That's the kind of the intention of it.
Again, it's all up to the computation really at the end of the day. But
the key thing is the signaling, however you want to compute, use it,
reuse it and from there.
[Kireeti Kompella] The computation is the fun part.
[Lou Berger] Probably wearing a couple of hats.
I think this is really interesting work and I think it will help us in
Detnet where we have the need for for DAG signaling to support what is
called RAW (Reliable and Available Wireless), RAW-aware Detnet, where
the architecture talks about DAG, but we have no solution. So that
aligns very nicely.
The other thing that we have in Detnet, which this could help with, is
support for pre-off, where we do basically a form of one-plus-one
protection.
And we talked about this briefly in one of the earlier IETFs during
earlier presentations: if you allow not only single delivery at a
junction, but also multiple replication, then you can support either
one-plus-one or even one-for-n protection.
And that is another thing we have in Detnet, and obviously, in TEAS WG
in the past, when we didne-plus-one, one-for-one and one-for-n, so
covering that would be interesting.
I note that there is a protection section that is blank in at least one
of the documents, so maybe that would lead to it.
[Kireeti Kompella] Replying to the second comment from Lou: there is
something called MCTE (multicast TE) which is not point-to-multipoint,
but allows replication.
You have a segment and you can have a junction at which you want to do
not load balancing but replication and so that might help you with your:
I want to send multiple packets and pick the right one when I get to the
egress.
I will talk about MCTE later, so you can come back and give us
(feedbacks on) whether it fits or not at that point.
[Lou Berger] To be clear, I'm saying we look for you to provide
solutions that help us in Detnet, not that I am interested in doing the
work.
I was speaking more as a chair that it would help us in Detnet.
So if you are looking for use cases or additional support, I think if
you bring it and say this will support support these Detnet use cases,
you'll get people saying, yes, we like that
[Zafar Ali] My comment is about the draft-kompella-teas-mpte.
Thanks Kireeti for the presentation, but the problem and the solution is
15 years too late: it has been solved, implemented and shipped using
SR-TE policies.
There is RFC9256, you would like to take a look at that: it has detailed
all of these aspects you talked about here.
And then thanks to Andrew for presenting how SR solved the problem for
MPTE: it is an informational draft which proved that this construct
already exists and people have been using and shipping.
I do not have problem: if we want to document, it is fine, if you want
to generalize whether tunnelling is fine. But, I am mentioning the next
part because the document does talk about SRv6 tunneling in it, it has
the content.
So I find it a little bit challenging and difficult to read when the
document posed this problem, solved for 15 years, as something that has
been invented today.
It is how it is written, that's how I read it. So it was represented
like this and then its references are basics and does not even
acknowledge RFC9256. Instead, SRv6 references SRH which is not relevant
for this discussion.
So I don't know what is this, but without acknowledgement for the proper
work that is already done, I consider it as academic dishonestly. I
think, I like authors to consider this, that at least reference the
right thing and position it correctly.
[Kireeti Kompella] I would like to thank Zafar for calling me
academically dishonest. I am completely thrilled. Thank you.
Poll: Is MP-TE a topic of interest for TEAS WG?
Poll result: 21 yes,3 no, 8 no opinion
[Oscar Gonzalez de Dios (as chair)] We are seeing a reasonable number
of supporters, not as much as for power-aware TE. We have three voices
with No.
For the people that is saying No, it here any new argument, different
from the ones that we have already heard before, that you want to raise
now? Otherwise, please raise those arguments to the list so we can bee
aware of them.
Poll: Is this document a good starting point for discussing the
architecture for MP-TE?
Poll result: 21 yes, 2 no, 3 no opinion
[Oscar Gonzalez de Dios (as chair)] We have almost the same number of
people who have said that MPTE was worth that say Yes. There are still a
few without opinions, so I guess they need to read the draft more in
detail before taking an opinion. There are a couple of voices against
it. It's because they are the ones answering before that MPTE was not an
interesting topic.
If you think that MPTE is an interesting topic but the architecture
document is not a good starting point, please raise your voice now. I
think we would like to hear those opinions.
The discussions here are not personal, it's just technical, so please
raise your voice because I think it's very interesting hearing all the
opinions and all the views.
If you do not want to stand up and show your face, you can also use the
list to send it, please.
Poll: Is this document a good starting point for defining the data
model for MP-TE?
Poll result: 16 yes, 1 no, 8 no opinion
[Oscar Gonzalez de Dios (as chair)] I have a good number of support.
Of course, not as much of the architecture but I think is a very good
numbers here. We are so a lot of no opinions. I guess we need also more
time to go through the documents.
Poll: Is this document a good starting point for defining the
RSVP-TE based signaling for MP-TE?
Poll result: 14 yes, 3 no, 15 no opinion
[Oscar Gonzalez de Dios (as chair)]
[Vishnu Pavan Beeram (from Zulip)] draft-stone-spring-mpte-sr
describes how to realize MPTE (as discussed in the MPTE architecture
document [draft-kompella-teas-mpte]) in Segment Routing networks using
existing SR building blocks: SR Policy and Binding SID at each junction
that makes up the DAG, managed by a centralized controller. Each transit
junction resolves a BSID to invoke a per-junction SR Policy. As a
co-author, I believe this document is ready for adoption (in SPRING, of
course).
[Vishnu Pavan Beeram (from Zulip)] I would also like to draw your
attention to draft-ajp-spring-srv6-mpte — this takes a different
approach (that works with or without a controller) for SRv6 networks.
Instead of per-junction Binding SIDs and SR Policies, each MPTED tunnel
uses a unique DAG Locator and DAG SID as the SRv6 forwarding context.
Transit junctions perform plain IPv6 forwarding on the DAG Locator
prefix — no Endpoint Behavior execution, no Binding SIDs, no
per-junction SR Policies needed. We'd appreciate a read and feedback on
the SPRING list.
Draft: draft-kompella-teas-mcte-00
Presenter: Kireeti Kompella
[Andrew Stone] I will not make a SR writing version of this, because
it looks very similar to replication segments.It's probably best to see
how the replication segments is doing this.
So especially in the BGP signaling actually.
There is a draft in PCEP to do replication segment for
point-to-multipoint policy already. So if you were to do, for example, a
PCEP signaling, to me whether this gives you more than what the SR
solution does, I would struggle with that same with that. Same with BGP
signaling: BGP already has it: it essentially does junctions just
through replication nodes.
I don't know now from an RSVP-TE signaling, if that's what do you want
to do, but there is a lot of overlap here.
The other side is something to think about long-term that actually gave
us a lot of work and tests to figure was the optimizations. And so doing
optimization for the replication segments, local or global optimization,
is not trivial.
And I just wonder in a DAG design, if you're going to do optimization on
the DAG, obviously you can tolerate things differently, you can
reoptimize differently, whereas in the multicast, it can loop really
badly really quickly.
So I struggle to see if the DAG signaling concept, with RSVP-TE, how
complex that optimization might get.
So just a few comments to say that there's overlap here.
There might be reuse, it's worth kind of exploring that whole hierarchy
of replication segment.
[Daniel King] Following up the optimization question, does this
consider things like Steiner versus non-Steiner path computation,
minimized cost of the overall tree versus shortest path, etc.?
And so would that sort of be part of the PCEP extensions?
[Kireeti Kompella] The computation is not specified in any of these
documents.
I think you can do all of those different optimization, so Steiner Tree
versus whatever else you want to try.
Having done that, now you want to signal, and typically these are trees.
In principle, you could have a combination of replication junctions as
well as load balancing junctions, you have to be really careful not to
have packet replication at the end, unless you really want it (in some
cases you do).
But again, the computation is orthogonal to this: once you decide the
shape of the tree is, assuming it is a tree, you can use this concept to
signal it versus using multiple sub-LSPs.
[Lou Berger] This is a long context switch, I mean we are going back a
lot of years. But you're making me remember some conversations we had
with Rahul Aggarwal who is the one who came up with the sub-LSP.
Part of the reasons that ended up there is because it allowed for
different implementations to do different things. I may have it wrong:
Pavan has done much more on the implementation side than I have,
particularly recently. So, Pavan, you can correct me.
My memory is that you could either signal sub-LSPs individually or you
could signal them as a group. If you signal them as a group you had the
advantage of collapsing the state. If you signal them as individually,
you ended up with that degenerated case.
So, my question back to you is: are the advantages more because of an
implementation choice than a protocol design choice?
And that can you implement your junctions using the same sub-LSP concept
but instead of signaling each individually to do them as originally
envisioned as a group?
I think it is worthwhile analyzing to make sure we are just not
overcoming an implementation choice rather than a protocol design
choice.
[Kireeti Kompella] So it's an excellent question, and I did go back
over the RFC and I did notice that you have this.
The implementation choice that we made is actually multiple sub-LSPs,
with lots of Path messages. So the example I gave is more reflective of
a particular implementation rather than of the choices offered in the
RFC.
However, even if the RFC has this notion of a group, which means with a
single message I am going to send you multiple things, as far as I
understand, you are still going to create a lot of PSBs.
[Lou Berger] No, it is a single PSB.
I know we're going back to ancient history, but this was a compromise to
allow a particular vendor to more quickly implement a solution. So I'm
not going to tell you it was optimal. It was a compromise in a standard
group to allow different people to come to the table and say, I really
want to signal it with a single PSB and someone else to say I really
want to implement it fast and it allows me if the individual sub-LPSs
allowed me to get there faster.
I think you're hitting an implementation choice and wanting to revisit
that. I would just ask to go see if you can revisit it without changing,
or with minimum change to the protocol.
[Oscar Gonzalez de Dios] My suggestion is to do now with multicast
also what you have done for the other MPTE drafts: to have some
operators, some carriers, where you can also try to prototype it and
then we can see the interest.
Draft: draft-zdz-teas-5g-slice-ipextension-00
Presenter: Cheng Zhou
[Nathan Harold] I just wanted to say that this feels like a very blunt
sort of approach to the problem and I would like to understand what
other things you've considered that don't involve adding 12 bytes to the
packet headers.
And also I'm curious about the practical implications of the slice ID,
whereas if it's really about QoS, it feels like the slice type should be
enough.
[Vishnu Pavan Beeram] Please respond on the list
Drafts: draft-xkk-teas-hpc-tunnel-realization-00
Presenter: Quan Xiong
[Vishnu Pavan Beeram (as chair)] The first two modules probably are
not for the TEAS WG, but the third one, where you are augmenting the TE
tunnel, may find an home here.
Make sure you socialize that with RTGWG.