Tuesday 8 November 2022
Room: Richmond 4
09:30-11:30 UTC
Log into the IETF datatracker to access:
Presenter: Rakesh Gandhi (rgandhi@cisco.com)
draft-jags-mpls-mna-hdr
Greg Mirsky: Special attention to end-to-end operations of MNA when MNA
is expected to operate on the egress. There are other options such as
Hop-by-hop (HBH) and select. Different modes could be combined or not?
For example, IOAM is HBH, while generic flow indicator is end to end
(I2E).
Rakesh Gandhi: Yes. There are sub-stack for HBH and substack for I2E.
Only requirement for backward compatibility is if the node receiving the
packets does not understand the MNA bSPL then it will drop packets. Only
constraint is the ingress node needs to ensure that the bSPL is not on
the top.
Greg Mirsky: Rephrase. Maximum stack along the path we can put HBH and
I2E at the bottom of the stack. With the current encapsulation, is it
possible to do both network actions (HBH and I2E) with one special label
or two special label, i.e. two NASS?
Rakesh Gandhi: One special purpose lable can have multiple substacks
with different scopes. We can have one substack for HBH to carry IOAM,
another for I2E to carry generic flow indicator.
Presenter: Liuyan Han (hanliuyan@chinamobile.com)
draft-dong-spring-srv6-inter-layer-programming
Sasha Vainshtein: Slide 2, optical path O1 to O3, IP path P1 to P3, when
P3 receives an IP packet from P7, how to know which layer 2
encapsulation should be put on this packet before being sent over the
optical path, since without this encapsulation P3 will not recognize the
packet is an IP packet thereby wont be able to forward. It seems that it
is impossible. Whether P3 could forward?
Ran Chen: Agree with the use cases and the requirement on the SRv6
interlayer programming. We have similar proposals.
Ketan Talaulikar (partially from jabber): Follow on Sasha's comments. It
is not clear whether the optical path is IP or not. End.X in RFC8986 can
be used for L2 bundle member and for steering into optical path. Don't
see any reason that we need this new behavior. Please look for L2 bundle
member in the 4.2 section, End.X can be also used for the scenario
presented in this draft.
https://datatracker.ietf.org/doc/html/rfc8986#section-4.2
Jie Dong: Details on whether P3 can correctly recognize the packets and
forward them are not covered. We could distribute this information in
the control plane. End.X is only used for Layer 3. End.XU is to separate
from the Layer 3 topology. We dont want to mix the Layer3 adjency with
underlay links for some network behaviours. So we can have different
path computation for different services. That is the purpose.
Presenter: Yisong Liu (liuyisong@chinamobile.com)
draft-liu-bfd-srv6-policy-encap
Greg Mirsky: Why is the encapsulation for BFD so special? I cannot find
any difference or specific things.
Yisong Liu: Just work on how to encapsulate BFD with SRv6 policy. Maybe
minor difference.
Greg Mirsky: If you suggest BFD should be encapsulated differently from
payload, how you could guarantee it is not treated differently? What are
you monitoring? The packet will not follow the same path.
Joel: We need to take it to the list since we are short of time. It is a
good question.
Shraddha Hegde (partially from Jabber): Why to define two different
modes? One mode seems to be enough. It seems with transport mode, all
usecases for detecting liveness of the segment list can be satisfied.
Yisong Liu: Cannot hear clearly.
Gyan Mishra: Is there anything special we defined in this draft other
than the standardised SRv6 network programming?
Yisong Liu: We did not change anything. Gyan: What are the benefits to
be added by this draft? Yisong: (no answer)
Jeffrey Haas: (BFD Chair) Five drafts aimed at spring regarding BFD. My
suggestion to the WG, rather than having five different drafts, please
consider taking one draft.
Joel Halpern: We certainly want to see the authors pull together.
Presenter: Liyan Gong (gongliyan@chinamobile.com)
draft-gong-teas-hierarchical-slice-solution
The authors request WG adoption.
Ted Hardie: Three questions: 1) Informational draft? What work you want
SPRING to take? 2) One level of hierarchy managed by SR, and the other
by something else. Would it be possible for your approach? 3) any IPR?
Liyan Gong: It is informational. No extension required. Just to post to
see whether there is any confliction with SPRING. The first level is
using Flexalgo for the control plane, which is usually hard to have
multiple slices. The second level is for the data plane and also based
on SRv6. I am not aware of any IPR.
Gyan Mishra: Is there any example for this two layer hierachy? More
layers can also be ok? Any special requirements are related to this?
Liyan Gong: Current for CMCC it is only two levels. One example is
different buisness units to the operators such as government and
enterprise, etc. The other example is that CMCC has several
sub-operators located in different provinces who want to run their
businesses independently.
Presenter: Gyan Mishra (gyan.s.mishra@verizon.com)
draft-peng-spring-pmtu-sr-policy
Gyan Mishra: Asking for WG adoption.
No questions.
Presenter: Swadesh Agrawal (swaagraw@cisco.com)
draft-agrawal-spring-srv6-mpls-interworking
The authors request WG adoption.
Dhruv Dhody: For the PCE part, currently you only focus on a single PCE
case. Just to have a look at the draft in PCE WG
(draft-ietf-pce-stateful-interdomain), so it could also cover the
inter-domain multiple-PCE case.
Swadesh Agrawal: Will look at it.
Jeff Tantsura: How to deploy end-to-end? Need a section in the draft to
cover operational details!
Swadesh Agrawal: Looking for operational aspects? Jeff: Yes. Swadesh: We
will work on this.
Jorge Rabadan: No need to have this in the BESS draft?
Swadesh Agrawal: We have put it in the early version of this draft. We
need the new behavior so that is why we put it out.
Presenter: Liyan Gong (gongliyan@chinamobile.com)
draft-cheng-spring-sr-policy-group
Ketan Talaulikar: On the information model, does this newly defined sr
policy group belong to the headend or the controller?
Liyan Gong: Do you mean that the sr policy group has a headend?
Ketan Talaulikar: So it is headend. It would be good to update the draft
to cover what can not be done with what we have today.
Weiqiang Cheng (Co-author): The proposed policy group will not introduce
any change to the data plane. We use it based on controller or
management system. We can use sr policy group to do the hierarchical
slicing.
Ketan Talaulikar: What are the extra value? More clarity are needed.
Weiqiang Cheng: It could help to organize different sr policies of the
same user or service. It would become easier to use this to help set up
the hierarchical services based on SRv6 policies.
Ketan Talaulikar: Why to standardize it? You should bring functional
value for standardization purpose.
Boris Khasanov: We have two colors. One is for sr policy group and the
other is for sr policy inside the group. How does it work?
Weiqiang Cheng: We just use one color for one parent policy. Within the
parent sr policy, different services can have different colors. Similar
to HQoS.
Presenter: Wenying Jiang (chengweiqiang@chinamobile.com), Wenying Jiang
(jiangwenying@chinamobile.com)
draft-cheng-spring-srv6-resource-programming
Gyan Mishra: How are you mapping the NRP to QoS?
Weiqiang Cheng (Co-author): NRP may exist in the controller for
provisioning. How to attach the NRP to the forwarding layer? It is hard
for the controller to manage the dedicated resources in the forwarding
layer. END.NRP can set up a good and simple solution for the forwarding
layer to be attached. It is helpful for the leased line services.
Gyan Mishra: It is like the HQoS.
Weiqiang Cheng: Yes.
Jie Dong (from Jabber): There is a WG document on resource-aware
segments, which is to associate network resource attributes with SR
SIDs, it seems a reference to that document is needed.
Presenter: Wei Wang (wangw36@chinatelecom.cn), Aijun Wang
(wangaj3@chinatelecom.cn)
draft-wang-spring-multicast-vpn-segment
Bruno Decraene: Did you ask for a slot in BESS? Wei: No. Bruno: It is
better to present there. Wei: ok, we will.
Sasha Vainshtein: The solution can only work with the ingress
replication as provider tunneling technology for MVPN because the
End.MVPN includes the RD of the multicast vrf in the egress PE. RD is
specific to each egress PE. In order to make it work, the ingress PE
needs to send dedicated packet to each egress PE where the sepecific
MVPN service is instantiated. This should be specified in the draft.
Aijun Wang (Co-author): For the multicast scenario, the RD for all the
egress nodes should be set a unique value. Our draft just describes the
format.
Sasha Vainshtein: It is not the normal MVPN behavior. If you start from
the unicast VPN and then upgrade to the multicast VPN, you dont need to
change the RDs. If this is the assumption, you should state this in the
draft. No relevant text in the current draft. It should be presented in
BESS since it includes the BGP part. The question will be raised.
Aijun Wang: For the unicast solution, the RD can be set differently or
uniquely. In the next version of the draft or presentation, we will
state that the RDs of all the egress PEs of MVPN will be set the same.
Gyan Mishra: Does it follow the MVPN procedures? Or is it completely
different?
Aijun Wang: It mainly focuses on the scenarios in the native IP networks
So the procedure is different from the traditional MVPN solution.
Joel: The queue is closed. We are over time already.
Presenter: Gurminderjit Bajwa (gurminderjit.bajwa@telus.com)
draft-zzhang-spring-microtap-segment
Speaker Shuffling Time/Buffer: 5 minutes
Total Presentation Time: 120 minutes