WG ICS: https://datatracker.ietf.org/meeting/124/session/34746.ics
Datatracker: https://datatracker.ietf.org/group/teas/about/
11:30-13:00 America - Eastern Time - Montreal
https://www.timeanddate.com/worldclock/converter.html?iso=20251104T163000&p1=165
Room: Centre Ville --
https://datatracker.ietf.org/meeting/124/floor-plan?room=centre-ville
Materials: https://datatracker.ietf.org/meeting/124/session/teas
Note taking: https://notes.ietf.org/notes-ietf-124-teas
Onsite tool: https://meetings.conf.meetecho.com/onsite124/?session=34746
Video stream: https://meetings.conf.meetecho.com/ietf124/?session=34746
Audio stream: https://mp3.conf.meetecho.com/ietf124/34746.m3u
Zulip: https://zulip.ietf.org/#narrow/stream/teas
Recording: http://www.meetecho.com/ietf124/recordings#TEAS
YouTube: https://www.youtube.com/watch?v=34G6BFBmppc
Luis M. Contreras: On slide draft-ietf-teas-5g-network-slice-application
We have received feedbacks from one of the 3GPP WG and w could expect
feedbacks from other 3GPP WGs.
This is the reply from RAN WG3 which have mostly identified the point
that all the front haul stuff from ORAN is not part of 3GPP. We will fix
the comments there.
In addition to these public feedbacks, I have also received feedbacks
fom the chair of another group so it seems that other WGs in 3GPP are
analysis the document so we can expect more feedbacks.
We are planning to aggregate all the comments and produce a new version
and consolidate all the comments in this new version.
Vishnu Pavan Beeram: pleae propose the edits on the list and have the
discussion going on while waiting for other comments to come.
Nigel Davis: Firstly, this should be done in RFC8345 and not in TEAS
because the multipointed topology requirement is across the board
clearly.
Secondly, a multipoint link would be a more efficient mechanism as we
presented in RFC8345 enhancement proposal, so I would suggest to do this
in RFC8345 and not here.
Italo Busi: There was a long discussion many years ago about how to
split the work between RFC8345 and RFC8795.
Actually it was before I have started to be very active on this topic,
so I do not know how the split has been decided but RFC8345 clearly
states that the multipoint link is modelled as a pseudonode but it does
not say whether a pseudonode or even a node has or it does not have
connectivity limitations.
So when you see a node in RFC8345 you have no information about whether
you can connect everything or cannot connect anything or you can connect
only a subset. This gap has been already addressed in RFC8795.
Nigel Davis: It should have not been in RFC8795
Italo Busi: Ok, if should not, but now it is already there
Nigel: So we should take it back to RFC8345 making the adjustment and
taking it out of your document
Italo Busi: That means that we are going to have a non backward
compatible change because you need to take it out from an existing model
Nigel: You can keep it in and have both and say that we deprecate it and
eventually do an RFC8345 mechanism
Italo Busi: Ok, deprecate from RFC8795 but those who have already
implemented it will need a NBC migration
Nigel Davis: We can keep it deprecated for 10 years
Vishnu Pavan Beeram: We have always maintained that RFC8795 is a
TE-aware topology. It does not say this in the title but it does include
node and link attributes which are not necessarily TE attributes, but
they have always been there.
You can start a thread on the TEAS WG mailing list and see where it
takes us. What we are talking about is taking what is already there and
create multiple profiles out of it.
Nigel Davis: I understand but we should be doing this in RFC8345 which
is a generic document since this is a generic problem and not a TEAS
problem.
Vishnu Pavan Beeram: When you say it should be done in RFC8345, you mean
it should be done in NMOP WG, right?
Nigel Davis: Yes
Vishnu Pavan Beeram: Let's have a conversation offline also with the
NMOP WG chairs and see where that work needs to go. However, the scope
here is to take RFC8795 and creates profiles for it to make sure it can
be used in environments which are not necessarily TE-centric but there
is TE awareness. With TE awareness we mean that TE attributes are still
at play in that.
Nigel Davis: Ok for me but we need it more generic than just TE since it
applies to any topology.
Italo Busi: I think the question is whether connectivity constraints on
the node is TE awareness and that is the issue of the blurring boundary
between RFC8345 and RFC8795 which was discussed more than 10 years ago
Nigel Davis: We do get things wrong sometimes
Italo Busi: That's fine
Nigel Davis: Another point about the node. I completely agreed that the
node has to be constrained. But, when you put constraints inside the
node, you actually build a small topology inside the node which you
might as well bring out to the edge and connect up to the edge and it
becomes a multi-pointed link which is much more efficient than having
links to a node.
It's just a more efficient mechanism and we can show that what you put
inside the node you simply have to put inside the link and then get rid
of all the links around the outside.
Italo Busi: I have looked at the proposal in NMOP WG and I do not see
any difference in terms of efficiency with respect to the pseudonode.
Vishnu Pavan Beeram: Please take to the list
Daniele Ceccarelli: This is a very useful work but with the wrong name
in the wrong place. We realized that if we keep calling it TE whatever,
people will stop reading it after the abstract because their network is
not TE.
One suggestion is to call it differently like RFC8345 enhancements for
... something that is not TE and try to move it maybe to NMOP or maybe
ONIONS, getting rid of TE-awareness, TE networks, focusing on everything
which is an enhancement of RFC8345 and that is needed for other work.
SIMAP is an example but there are maybe other examples.
Italo Busi: Good suggestion. I understand TE is an "unpolite word" and
that's why I have started in this document not to empathize too much the
term TE but using the term YANG model defined in RFC8795. We can also go
into the direction of RFC8345 extensions.
However, IMHO, there are two issues: some data nodes and container are
already called TE and the YANG module is already called TE. Changing
these names with different names is defining an NBC change.
One option is to basically create a new YANG data model which is a copy
of RFC8795 with a different name, replacing TE with something else. But
this is making a big problem to operators which have already deployed
RFC8795 which need to migrate from RFC8795 to a new model. From vendor's
perspective is not a big issue but from an operation perspective
operators need to migrate just because the name is not good.
It looks strange but I am open to this option.
Daniele Ceccarelli: I am reading this draft since the -00 version and I
know there is a lot of stuff which useful beyond TE. The issue is about
people who are not in the TE world stop reading it after the first line
and it is a pity since it contains a lot of good stuff.
Vishnu Pavan Beeram (not as chair): I respectfully disagree with what
you said. If anyone think they do not want to read the document just
because there is TE in the abstract we should try and correct that. We
are not going to fix that in this session. We will discuss on the list.
Olga Havel (from Zulip): We will present the NMOP proposal for RFC8345
extensions at the SIMAP side meeting at 6:30 today. Please join if you
are interested.
Both for bidirectional, multi-point and other SIMAP requirements not
supported by RFC8345
Italo Busi (from Zulip): Bidirectional and multipoint links are
supported by RFC8345: please read section 4.4.5 of RFC 8345
Olga Havel (from Zulip): In a simple way, based on SIMAP requirements.
We have clarification in the draft draft-havel-nmop-simap-yang, sections
7.10.1 and 7.11.1
For operator requirements for SIMAP / topology please see
https://datatracker.ietf.org/doc/draft-ietf-nmop-simap-concept/07/. It
is ready for the last call.
Lou Berger: Why only Netconf versus YANG and not Restconf, gNMI?
Tony Li: We are not precluding any configuration mechanism. This was
already in the document and we are carrying it forward.
Lou Berger: Was in what document? Not in the original document because
Netconf was not existing at that time.
Tony Li: If you like us to add anything else we are ok to do it.
Lou Berger: I think you should switch to a YANG-based approach and not
care about the transport.
Tony Li: Ok
Zafar Ali: I am not a crypto expert and when reading the document there
are many things I do not understand. I am not sure if other people are
in the same boat but I am wondering what is the plan to have this
reviewed with the Security Area
This draft should be reviewed in the Security Area
Vishnu Pavan Beeram: The adoption call was sent to the relevant groups
including SAAG group as well. We have also triggered early SecDir review
and reviewers have been assigned. So that activity is happening.
Tony Li: And we have got some comments from these reviews which have
been already addressed.
Zafar Ali: Ok, thanks.
Vishnu Pavan Beeram: There were some offline comments sent by reviewers.
It will be useful for the community if you can summarize to the list.
Vishnu Pavan Beeram: Is it fair to assume that you are modelling the TE
topology for DCI and not the DC topology?
Luis M. Contreras: Yes
Vishnu Pavan Beeram: You are taking the TE topology in the DCI and
augmenting the attachment circuits with additional compute and workload
information. Is that the scope of this draft?
Luis M. Contreras: Yes, we are not entering on the internal of the DC
neither touching the DC gateway. Just reporting what will be the
resources available or the workload attached to a specific border node
in the topology of the network.
Vishnu Pavan Beeram: The chairs have discussed on the next steps but not
yet come to a conclusion. They will discuss with other WG chairs in
Routing Area and decide what to do and let you know.
Lou Berger: I agree on BCP as soon as we have an RFC for auto-bandwidth
Zafar Ali: I agree
Vishnu Pavan Beeram: Since we do not have an auto-bandwidth document in
IETF, there was a comment in last IETF about writing a BCP for RSVP
auto-bandwidth deployments. This draft is a specific feature that can be
used off of auto-bandwidth environments as well, so there is enough here
to be progress as an individual item.
Lou Berger: I have no objection to the document. I do not think this
document should talk about a BCP for auto-bandwidth until we have a BCP
for auto-bandwidth, or even a definition.
I think there was a PCE document on auto-bandwidth you can steal a lot
from and it should not be an hard thing to write and it would be a great
thing even if it has been deployed for many years.
Vishnu Pavan Beeram: There is a PCE document on auto-bandwidth but there
is no generic document even if for many years we have made enhancements
in the auto-bandwidth area. So, the comment was that having one document
that captures all of that was useful for the community.
Lou Berger: I think we are in agreement that we should have a document
on auto-bandwidth.
Rakesh Gandhi: I think it should progress as a Standard Track document
by its own for in-place bandwidth updates. For auto-bandwidth, there is
a PCE document which was highly appreciated because there was none
before, so if there is something to be done, it could be aligned with
the PCE work.
Have you thought whether this draft should update RFC3209, in any way?
Zafar Ali: I think we can have a conversation on the tagging.
Matthew Bocci: I think this is definitely worth progressing. It is very
useful to have this documented because this exists in the network.
I have few comments on the clarity of the text about how the LSR is
supposed to infer it is supposed to do this. I do not think this is very
clear in the document but I will send you offline these comments.
I do not think it is updating RFC3209 since it is not really changing
the base RFC. It is just an optional behavior that you can have. It is
arguable but maybe it is just Information
Zafar Ali: Thanks. I welcome your comment and I tend to agree with you
on the tagging.
Lou Berger: +1 to Matthew.
Zafar Ali: We are formally requesting the WG adoption for this document.
Vishnu Pavan Beeram: I am a co-author so Oscar will go through the
proceedings and make a call on this.
Zafar Ali: There is a draft in SRv6OPS, called AI back-end, that it is
doing this traffic placement using SR. It is in SRv6OPS because doing
this does not require any change to SR, because multi-path has been in
SR from day zero. So SR supports multi-path and multi-path TE.
There is a draft from Andrew as well which actually extends the MPTE
instantiation in SR.
Andrew Stone (from Zulip): FYI regarding the SPRING document discussing
achieving MPTE with SR/SRv6:
https://datatracker.ietf.org/doc/html/draft-stone-spring-mpte-sr
Kireeti Kompella: Thank you
Altanai Bisht: I have some concerns about the junctions. How much state
is needed in each junction and how you make sure that it propagates all
throughout the network, if there are different DCs or different clouds?
Kireeti Kompella: You have as many junctions as you have nodes in DAGs
and you can have multiple DAGs. The state that a junction has is: what
are my P hops, what are my N hops, what are the nodes and links that are
feed into me, what are the nodes and links that I am going to use to get
the traffic to the next step and what is the load balancing share among
the next hops. So, it is not a lot of state.
Altanai Bisht: Ok, so just the neighbors.
Altanai Bisht: How do you prevent a looping scenario where a DAG is
broken and there is a looping going on?
Kireeti Kompella: You run a CSPF today that produces a set of shortest
paths from any set of nodes to any set of nodes, without TE with no
looping. What we are doing here is eliminating some links because they
do not satisfy the TE requirements. Other than that, we are using the
same algorithm so looping is not seen as being an issue here.
Altanai Bisht: How do you handle failures? Every one of these junctions
are single point of failure.
Kireeti Kompella: If a junction has multiple next hops, it can handle a
failure by changing the load balancing weights among those.
But if a junction has a single next hops, we fall back to how we do it
today with RSVP-TE, which is either to create a detour or to create a
by-pass LSP. A by-pass LSP is typically shared among a lot of tunnels
while a detour is specific to the tunnel. But there are methods to do
that.
However, you have good point because we have not written that down. In a
future version we will write down in more detail how failures are
handled.
Altanai Bisht: I have also other small questions, I can send you
offline.
Vishnu Pavan Beeram: Please share them to the list so they will be
useful also to the community.
Wim Hendricks: You make some statements on that it improves the
performance. Have you real test with like real collective measurements?
My experience is that if you do not tie into the collective layer, you
can do whatever you want in the network but sometimes the effect is
opposite of what you are trying to achive from the network.
Kireeti Kompella: I think both on the collective but also just in MPTE
in a regular WAN network, our goal is to finish the implementation and
then compare in different conditions, like auto-bandwidth or recovery
from link failure or other changes, how classical RSVP-TE and RSVP for
MTE can work. Later we can do it with BGP and others but for now we can
compare RSVP with RSVP.
We think this will be more efficient but we need to complete the
implementation to be able to compare the efficiency.
Hopefully by the end of the year we have a sufficient implementation to
come back with numbers.
Wim Hendricks: If we have some real data at some point, it's good to
share so we can compare.
Kireeti Kompella: It is a good point and maybe in Shenzhen we will have
those numbers.
Rakesh Gandhi: I assume that in all the links in the network there is
telemetry that is used by PCE to collect all the data for all the links
in the network and that's how the topology is populated, right?
Luis M. Contreras: We are not entering into the solution, but a
potential solution would be to have T1 or stamp in the link, collect the
information and store it into the TE database. So the data can be stored
in an external database and the PCE just simply consult the database,
being the component that crates the statistical distribution
Rakesh Gandhi: So what I could not find in the draft is the objective
functions. In PCE RFC, path computation includes latency and other
metrics and also define objective functions on how the path would be
computed.
It would be good if you can add to this draft objective functions using
PAM metrics.
Luis M. Contreras: Thanks for the feedbacks.