Thursday 26 July 2024
Room: Regency C/D
13:00-15:00, Local
Log into the IETF datatracker to access:
[WG Document Status]
Dhruv Dhody: There is work using the spring YANG models, but still have
pending issues. They are creating errors for all the other models which
are augmenting them. Please the authors keep them in track and update
them.
Alvaro Retana: Yes, please keep them up to date because of the
dependancies.
Zafar Ali (Chatbox): The SR Yang draft issue is identified and is being
fixed. Thanks for highlighting it.
[Proposed WG Charter Update]
Alvaro Retana: Please review the SPRING proposed Charter and make
comments.
Ketan Talaulikar: What is a SPRING node? This is not something that has
been defined. Do you mean Segment Routing node?
Alvaro Retana: Yes, noted.
Antoine Fressancourt: On the 1st slide of the SPRING proposed charter,
SR-MPLS network operations work is also included. Shall we deligate this
work to SRv6OPS and SPRING work on the protocol extensions?
Alvaro Retana: SRv6OPS is already chartered. RTG AD Jim may think about
it.
Dhruv Dhody: How can we achieve agreement on the ordering of the
milestones?
Alvaro Retana: Haven't figure it out. There was a related topic on the
milestone management in the alldispatch session on Monday. Agreement as
a working group means commitment, including reviewing, making comments,
and participating.
Tom Hill: On the 3rd slide of the SPRING proposed charter, I am
concerned that we have removed the word security entirely. We currently
have a working group draft on the security considerations, so we should
have the security word back. The word untrusted is not in there, which
should be included as well.
Alvaro Retana: If you have text in mind, please propose. One thing is
that we want to make sure we use terms that we have defined. There is a
definition of a trusted domain, so I am assuming that the inverse of
that is an untrusted domain.
Tom Hill: People usually say when the term is not there so we are not
doing that.
Alvaro Retanan: If we use the word untrusted we need to make sure that
we know what it means.
Tom Hill: We have a history here of arguing over very strange ambiguous
language, and I don't want to see it anymore. I will try to propose some
text.
Rakesh Gandhi: On the 4th slide of the SPRING proposed charter, I wonder
whether we should also include ippm working group in the list since we
have a lot of collaborative work.
Alvaro Retanan: Sure, please reply to the mailing list.
[draft-bdmgct-spring-srv6-security]
(https://datatracker.ietf.org/doc/draft-bdmgct-spring-srv6-security/)
Presenter: Luis Contreras
Alvaro Retana: We got a specific request from the IESG to start the
work. The request specifically was to look at the security
considerations in segment routing as it is defined, which means in
existing RFCs. Addressing security in upcoming work is out of scope for
this document. We plan to call for adoption of this document soon
because we have a commitment to the IESG and we want to move it as fast
as we can.
Tom Hill: Impressed with the rewrite. Better to also mention about the
SRv6 SID draft (draft-krishnan-6man-sids) in 6man. It would be well
worth expanding either 8.1 or writing 8.3 to cover the specific problem
of leaking things out of the trusted domain. In the draft, it mentioned
that some of the SRv6 compression mechanisms do not use an SRH, Section
8 should cover that in more details about the problem that will not be
able to distinguish these packets from the IPv6 packets. I will try to
propose some text as well.
Nan Geng: SRv6 is deployed in a limited or trust domain, also as
mentioned in the trust model section of the draft. This statement is a
solution or an assumption? If deploying SRv6 within a trust domain is a
solution, the description about the trust domain deployment request can
be moved to the mitigation session. If it is an assumption, then it is a
target or analysis case, and some of the attacks or threads are not in
the scope of the analysis.
Jim Guichard: Run this in the SRv6OPS and may get more inputs.
Alvaro Retana: We will also copy SRv6OPS when we start the adoption
call.
Suresh Krishnan: draft-krishnan-6man-sids is going to get an RFC number
soon, but you can refer to the block. To Nan's point, this is a
checklist. Don't want to apply this to trust or not.
Alvaro Retana: Please go to the mailing list and discuss.
Presenter: Ran Chen
draft-chen-spring-sr-policy-cp-validity
Ran Chen: We would like to ask for adoption.
Alvaro Retana: Before we consider the document for adoption, we need you
to cut the number of authors on the front page. I counted 7, we need 5
or less. Comments? Questions? Suggestions? Volunteers to review?
no responses
Ran Chen: Maybe we have discussed most on the list, so we have solved
all the questions. Maybe it is stable.
Alvaro Retana: Okay, so I guess we should move on.
Presenter: Liuyan Han (remote)
draft-dong-spring-srv6-inter-layer-programming
Sasha Vainshtein: An underlay path between two IP nodes. How should the
node at the remote end of the underlay link know what to do with the
IPv6 packets it has received? In order to do this, should the remote
node associate some IPv6 capable interface with this underlay? In this
case, you would not need any special behaviors. You only need normal
End.X behavior.
Liuyan Han: We can go to the use case slide, which is slide 3. When we
have IP and MTN network, the underlay nodes also have the processing
capabilities of the layer 3 in its client side. The MTN node can receive
the end behavior from its ingress interface, and then it can use this
SID to indicate which MTN path can be selected automatically. It can
bring many advantages for the end-to-end programming. It is visible in
the control plane when the underlay path is selected.
Sasha Vainshtein: Not sure that I have captured all the points.
Alvaro Retana: Please discuss in the mailing list.
Ketan Talaulikar: Slide 7, the statement here that End.X is only for
layer 3 is not actually accurate. The End.X description RFC8986 says
that we can allocate it for layer 2 bundle members, which we can think
of subchannels under layer 3 interface. So that is a layer 2 bundle
member this is optical subchannel. There is similarity. Two drafts are
better to be merged. We have two variants, one is End.xu and the other
is the binding SID variant. The draft is not clear on when we need the
binding SID and when we need the End.X sid. The feedback to the authors:
if you could consider coming up with one of them not two. This is just a
suggestion.
Jie Dong: A quick response to the comments. As per the definition in RFC
8986, End.X is for layer 3 adjacency. If we want to use the End.X for
non-IP layer and uni-directional link, that behavior would be different
from that for layer 3. Because for layer 3 you need a bidirectional
check for link to be visible and can be used for packet forwarding. For
this, we want to do some traffic engineering for specific kind of
traffic, so there is some difference between this and the normal End.X
behavior. To Sasha, the interface of the endpoints at the two sides does
not need to be layer 3 enabled. As long as they have the agreed
encapsulation you can build a transport channel no matter it is OTN or
MTN. You can forward the packets to the other side and then they can be
processed properly. So it is possible to avoid building the layer 3
adjacency between these two kinds of nodes because there is some
challenges in some scenarios.
Tom Hill: As a requirement for this to work, there has to be some form
of layer 3 connectivity between your IP routers and MTN routers or
switches so you can communicate across that boundary.
Liuyan Han: If we define this behavior, it may have some requirements
for the MTN nodes. Now since we list them in different areas or domains,
so the current SRv6 behavior can not enable the end to end programming
now.
Tom Hill: In most of cases which I am aware of, we don't tend to connect
these things together on purpose, such that they can't talk to each
other. I feel the title for this draft is very broad for actually quite
a limited set of circumstances whether it can actually work.
Liuyan Han: Some services have very strict requirements for bandwidth or
latency. If the services require low latency, we hope to choose a better
underlay path, that is, an optical or MTN connection. In CMCC, we have
long distance between DCs across different domains. We need to choose a
better path.
Tom Hill: No trust between optical network and IP network. This proposal
requires the trust between these two networks. I don't think it exists
in many situations, none that I am ware of. This is about the scope of
the draft.
Liuyan Han: We can use super controller, which can see all the different
network domains.
Tom Hill: In that case, that would not be a network programming job but
a PCE job.
Ran Chen: To Tom, the two domains of the network belong to the same
operator. CMCC has clear requirement and our company has implemented it.
CMCC has successfully completed the basic verification of this function.
We can talk offline for more details.
Tom Hill: Even if we own both of the networks, the optical and the IP,
we still don't trust each other, which is usually done on purpose. It is
a zero trust architecture. You segregate your networks on purpose to
make sure that they can't affect each other. I feel that is a very
common deployment.
(Chatbox: Suggest to check with TEAS and CCAMP.)
Presenter: Zhaohui (Jeffrey) Zhang
draft-zzhang-spring-microtap-segment
Greg Mirsky: This may be applied arbitrarilly to random packets. How
will this impact ECMP that uses their header information to generate
entropy?
Jeffrey: In SRv6 case, the ecmp hashing is based on flow label (Greg: it
is recommended and there is no requirement), so I don't see how this
will impact hashing. In the MPLS case, indeed, if your hashing is based
on MPLS label stack, you may have that issue there.
Greg Mirsky: I am opposite. Let's discuss in the mailing list.
Zafar Ali: We discussed this for SRv6 OAM. One of the problems is that
sometimes you do the samples of these packets for tapping. If you have a
sid it impacts the load balancing or hashing to the packet. The normal
flow and tap flow are different. We defined the O flag for the same
purpose, that is, it does send a copy of the packet and how the packet
is processed on the monitoring node further on is a local matter. In the
RFC, it is clear that all the processing is configuration driven. You
can just configure on the node that you want to tap from. I want to see
an analysis of why that was not used. There is another way of doing
replication. Replication segment is also defined. It is better to see
all these being discussed.
Dhruv Dhody: I think this is a document that could really use the
security consideration from the very start. This is going to come up.
Rather than putting it at the end, Let's analyze what should be the
threat model for this. A lot of details we have currently set out of
scope, which are mostly the operational aspects. There is a section on
PCE, but it doesn't describe what information does a controller taken
into the consideration. We should also consider the IETF policy on
Wiretapping (RFC2804) regarding whether "Tap" is a right term or not.
Presenter: Zhiqiang Li (remote)
draft-li-span-over-srv6
no comments
Presenter: Guozhen Dong (remote)
draft-dong-spring-sr-4map6-segments
Ketan Talaulikar: This work stems from the v6ops document that has been
referenced. I noticed that the v6ops draft does not talk about segment
routing or SRv6 at all. There is an extension also doing this in IDR
adopted by the working group which is also not using SRv6. What is
difference between those proposals and the one here?
Alvaro Retana: Please write in the mailing list.
Tom Hill: Need to describe why. Don't understand what the application is
and why we need this. We already have capabilities for IPv6 only SR-MPLS
domains, IPv6 only SRv6 domains, and we can carry IPv4 traffic across
those. I think that this is a very limited application here for this new
work. You could add a section that describes the intended deployment.
Guozhen Dong: For the case of IPv6 only deployment, IPv6 users need to
access to IPv4 services. Since the users only have IPv6 address, so the
approach needs to consider translations.
Tom Hill: We already have protocols existed. If there is no example you
can put in the document then perhaps a comparison with other
technologies that already exist.
Alvaro Retana: Please take this to the mailing list.
Presenter: Xiao Min
draft-liu-spring-bfd-srv6-policy-encap
Greg Mirsky: In the introduction, it stated that the demand mode is out
of scope. But this work covers BFD over multipoint networks RFC8562
which uses demand mode. We need to revisit and clarify the scope of the
documents whether it is applicable to multipoint network or it covers
demand mode. In the figure, you demonstrate a second IPv6 header. But
there is no discussion about how the destination address in this inner
header is selected. Selection of the DA in the inner header needs to be
clarified. Better to clarify whether IPv6 Encaps mode inner header or
IPv4 inner header? IPv6 Motivation for using Encaps mode compared to the
insert mode? It would be better to clarify the benefits.
Susan Hares: In IDR, we are going through a BFD strict mode. Is this
adhering to BFD strict mode? How does this affect the state machine in
the BFD strict or it doesn't apply? I am the shepherd for the BFD strict
so I am seeking information and help.
Acee Lindem: As an author of the BFD strict mode, that is based on the
BFD peers for the protocol so it is control plane while this is a data
plane verification of the paths that are specified. That just happened
to be provisioned using BGP.
Presenter: Yao Liu (remote)
draft-liu-spring-aggregate-header-limit-problem
Eric Vyncke: Slide 2, instead of using RFC8883 which is just ICMP I
suggest to use RFC9098 which is Operational Implications of IPv6 Packets
with Extension Headers.
Jeff Tantsura: What is the difference from the MSD?
Yao Liu: MSD is about the limit of the segment list in the SRH, but for
all the aggregate headers there is no such mechanism.
Jeff Tantsura: So what it requires new MSD type that signal addtional
metadata.
Sasha Vainshtein: Similar to Jeff. There is similar problem with MPLS.
There are well recognized mechanisms for making the controller aware of
these limitations.
Presenter: Balazs Varga (remote)
draft-varga-spring-preof-sid
Sasha Vainshtein: How this work can be combined with the SRv6 BGP based
services? The service instance is identified with an SID which is
advertised in a normal way from egress to ingress in BGP. How would you
combine this with the existing mechanism? Mostly you want to use Detnet
for services not just in the air.
Balazs Varga: We can discuss in the mailing list. We also have a draft
in the control plane regarding the signalling.
Alvaro Retana: Please read the charter and comment on the drafts being
presented here.