Minutes IETF112: rtgwg
minutes-112-rtgwg-00

IETF 112 RTGWG Agenda

Chairs:      Jeff Tantsura (jefftant.ietf@gmail.com)
             Yingzhen Qu (yingzhen.ietf@gmail.com)

WG Page:     http://tools.ietf.org/wg/rtgwg/
Materials:   https://datatracker.ietf.org/meeting/112/session/rtgwg
***************************************************************************

1. Meeting Administrivia and WG Update
   Chairs     (10 mins)

Jeff presented the RTGWG summary.

--------------------------------------------
Update of WG document:
2. SRv6 Path Egress Protection
   Huaimo Chen (10 mins)
   https://datatracker.ietf.org/doc/draft-ietf-rtgwg-srv6-egress-protection/

[Greg Mirsky] with regard to the SPRING SID compression. There is a
              decision to adopt the CSID proposal, but it's just
              beginning. I think it would be good to discuss how it is
              related to the SRv6 SID compression.

[Huaimo] I think SID compression is general to all SIDs.
[Greg] it is true, since this document is asking for WGLC, it would be
       good to address how it is used for this work. It's for the WG
       to decide.

[Acee] I am against it to hold this document until the SPRING SID
       compression is finalized. The SID compression won't be completed
       by next IETF.

[Loa] Agree with Acee. When we start WGLC, we should point out the
      compressions SID draft and mention the relationship.

[Acee]: fine with me. I just don't think we should hold the work unless
        it's on SID compression.

[Loa] I agree.

[Ron Bonica] Pointing to SID compression is like pointing to an unstable
             reference.

[Acee] You point to the compression draft in your email, not as a
       normative reference.

[Loa] yes, in the email of WGLC. It's like a downref, but should not
      hold up the WGLC.

[YingZhen] For all protection related drafts, we will sync up with the
           SPRIN chairs.

=============================================
Presentation 3-6 are new individual drafts, looking for community
feedbacks for future work:
3. Problems and Requirements of Satellite Constellation for Internet
   Satellite Semantic Addressing for Satellite Constellation
   Lin Han (20 mins)
   https://datatracker.ietf.org/doc/draft-lhan-problems-requirements-satellite-net/
   https://datatracker.ietf.org/doc/draft-lhan-satellite-semantic-addressing/

Maybe we can watch the video offline,
https://www.youtube.com/watch?v=M49yyJ0o5YU

[Stewart Bryant] you made an assertion that normal link state style
      convergence wouldn't be adequate for this. Mark Handley did
      simulation on Satellite and showed it worked really well. Can
      you explain the difference of the opinions?
https://youtu.be/QEIUdMiColU
https://youtu.be/m05abdGSOxY
Mark Handley's early work on this  simulations

[Han Lin] I know his research and simulation. Image a network with a
      couple of thousands nodes, and there are link flags every couple
      of minutes, it will be unstable.

[Stewart] He actually simulated the actual StarLink cluster. we need to
      be clear with real parameters, Mark was very convincing he thought
      he could do it.

[Zhenbin Li] is using semantic address, what is the forwarding table?

[Han Lin] if it's IPv6, it's the same as before. The question is whether
      we should use the same? we might not use the traditional routing,
      so we might use the forwarding table.

[Zhenbin Li]If not using forwarding table, what would you use for
      forwarding?

[Han Lin] We are looking for community input, to be aware of this
      challenge. If like Stewart said traditional routing works well,
      the we can just use that. But I'm doubtful about it. We may need
      new technology.

[Zhenbin Li] Is it research work or the work in RTGwg?

[Han Li]I don't know. I'll let the community decide. I've seen a lot
      of companies doing this, so we may need to provide a solution
      quickly.

[Rick Taylor] It is classic work in MANET, although nodes don't get
      added or removed often, but they do move in a predictable way. I
      agree with you classic routing may not work, but you don't have
      to throw the forwarding away. Discarding it is a big step. You
      may add some context info. I think it is a good topic to be
      discussed in Manet.

[Lin Han] We can discuss off line. It's very interesting topic.

[Rick Taylor] I would think of a hybrid solution, but this is something
      MANET deals with.

[Jeff T] I'd like to focus on Stewart's comments, look at the work done.
      Please review them and provide some discussion.

4. Accessing Cloud via Optical Network Problem Statement
   Sheng Liu (10 mins)
   https://datatracker.ietf.org/doc/draft-liu-rtgwg-optical2cloud-problem-statement/

[JEff] What is your intention for this draft? Are you saying to merge?

[Sheng Liu] find common ground and open to merge with the existing work
      about cloud access.

[Deborah] I noticed this is also presented in CCAMP. Just want to say
      that this is really the work in CCAMP addressing OTN work. VPN
      work has been on for many decades. They have done layer one VPN
      already. RFC 4974 adds more sophistication. As for the requirement
      for lower switching granularity, it is not in IETF; you should go
      to ITU-T SG15, quite active discussion there.

[Sheng Liu] we could evaluate GMPLS, and see whether there are some
      research work needed, such as multi-cloud. I agree LSU related
      work should be in ITU-T SG15.

[Cheng Li ] I am very happy to see the draft. We had a similar draft on
      IPv6 posted a year agon. Want to collaborate more.

[Haomian Zheng] A question to the WG, we see the two net2cloud WG
      documents expired and need to check with the WG if there is
      chances to further integration if there are common objectives
      and requirements.

[Jeff] : Deborah suggested this work may belong to CCAMP, we'll discuss
      with CCAMP.

5. Cloud-network integration
   Minxue Wang   (10 mins)
   https://datatracker.ietf.org/doc/draft-wang-rtgwg-cloud-network-integration/

[Cheng Li] We have a Cloud oriented network drafts with requirement
      and solution. Want to collaborate more.

[Jeff T]: do you mean the authors of the draft?

[Cheng Li] Yes. both drafts are informational, the scenario and
      requirements are similar.

6. Preferred Path Routing Framework
   Stewart Bryant  (10 mins)
   https://datatracker.ietf.org/doc/draft-chunduri-rtgwg-preferred-path-routing/01/

[Peter Psenak] I have a question on scaling. You tried to say the
      overhead in the packet, not mention the price of putting overhead
      into the IGPs. If you have many paths, how do you scale if you put
      this into IGPs?

[Stewart] We are not talking about entire Internet. it is might be the
      edge. There are more work on reducing the flooding.

[Peter Psenak] You mention flex-algo can do 128, so I assume you'd need
       more than paths.

[Stewart] We haven't talked about flooding reduction much about this
       work yet. You know where the info will be used.

[Peter] That is my the concern of putting too much in IGP.

[Terek Saad] There is a per path state stored or maintained on every
       node in the IGP domain, right?

[Stewart] we haven't talked about flood reduction. It definitely need
       to be store on the nodes that need to know about it, but that's
       reasonable.

[Tarek Saad] We have a draft of similar approach. The IP/TE path is
       programmed and present *only* on the nodes along the path by
       elying on RSVP protocol. As opposed to flooding in IGP and
       storing per-path state information in IGP on all nodes.
       reference:
       https://datatracker.ietf.org/doc/draft-saad-teas-rsvpte-ip-tunnels/

[Stewart] The current philosophy is to get rid of RSVP. using IGP can
       work with any network, like IPv4,. But replying on TE only works
       with MPLS network.

[Tarek Saad]: RSVP with extensions reference can program native IP
       paths. Just want to make sure there is per-path state maintained
       in IGP.

[Andrew Alston] I really like the this draft. We do have a need for
       lower cost technology. This is really useful for us.

[Stewart] really interested in knowing the use cases.

===============================================
A BoF on APN was held at IETF 111, and there were questions to be answered,
for example whether existing IETF solutions could be used (Detnet was
specifically mentioned). The team would like to present an update of their
work and address open issues.
7. APN. (25 mins)

   APN Framework and Gap Analysis updates
   Gyan Mishra/Shuping Peng
   https://datatracker.ietf.org/doc/draft-li-apn-framework/
   https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/

[Jeff] Please focus on the changes. We've seen the material multiple
      times.

[Terek Saad]Are you looking for per flow ID? or per group of flows ID?

[Gyan] one Flow ID can aggregate multiple flows. it's up to the operator.

[Terek] per Flow ID can be carried today in packets - and load balancing
      can work on that flow ID.

[Rick Taylor] I am glad you mention the QoS as the de facto for labeling
      applications. One property of QoS is When you traverse a tunnel,
      the QoS can be preserved. Do you consider the similar model? From
      the inside layer to the encapsulation?

[Gyan]Yes. The ID will be throughout the APN domain and removed after
      the domain.

[Rick Taylor] I really like this work. We have been searching for this
      for a long time. It is very useful. Totally support it.

   APN Header and IPv6 Encapsulation
   Robin Li
   https://datatracker.ietf.org/doc/draft-li-apn-header/
   https://datatracker.ietf.org/doc/draft-li-apn-ipv6-encap/

No time available for questions.

   APN FlowSpec and YANG
   Shuping Peng
   https://datatracker.ietf.org/doc/draft-peng-apn-bgp-flowspec/
   https://datatracker.ietf.org/doc/draft-peng-apn-yang/

[Greg Mirsky] what information in the profile to indicate the jitter,
      to be added in the IPv6 encap or APN, how they are used, for
      Forwarder? or local path selections? Let's discuss it on the list.

===============================================
The following draft is from ICCRG but considered relevant to RTGWG:
8. HPCC++: Enhanced High Precision Congestion Control
   Rui Miao  (15 mins)

   https://www.ietf.org/archive/id/draft-miao-iccrg-hpccplus-00.txt

[Robin Li] what is the intention of the draft? is it to ask for more
           work? we have TEAS WG and IPPM WG.

[RuiMiao] IPPM only specifies the format on packets. Our proposed work
          also include framework, logic, and path selection. We are
          hoping to create a framework, how to choose a route based on
          the the condition of a route.

[Jeff] This work is very interesting. we will be working in this area.

This presentation didn't happen due to time limitation.
The following is a BFD draft, since there is no BFD session it will be
presented if time allows: 9. Signal Degrade Indication in BFD
   Liuyan Han  (5 mins)
   https://datatracker.ietf.org/doc/draft-hwy-bfd-sdi/

*****************************************************
Chat History
*****************************************************

Lorenzo Miniero
Jeff: did you mean to use the preloaded slides? You're sharing the screen
instead 07:57:07 Andrew Alston did we lose audio? or just me - or no one saying
anything 08:00:27 Aahh there we go :) 08:00:56 Stewart Bryant Are the chairs
going to share the slides or do speakers need to share their own? 08:05:16
Yingzhen Qu all slides have been preloaded. so if you want to present yourself,
use the "share preloaded slides" icon 08:06:20 BEHCET SARIKAYA I read Lin Han's
draft-lhan-problems-requirements-satellite-net I think it is very informative
:) 08:06:27 Jeffrey Haas old rtgwg wiki: https://trac.ietf.org/trac/rtgwg/wiki
08:06:37 ~dhruv~dhody~ @chairs - Wiki for your reference
https://trac.ietf.org/trac/pce/wiki (also looking for ideas to improve it)
08:06:48 BEHCET SARIKAYA who is this lady talking in the background? 08:08:24
Jeff Tantsura Thanks Dhruv! 08:09:55 Yingzhen Qu thanks, Dhruv 08:10:44 Jeff
Tantsura my audio went away 08:11:32 BEHCET SARIKAYA SRv6 is kind of source
routing with all these SIDs, right? 08:12:11 I see that lady was Qu 08:13:02
Yingzhen Qu didn't realize you meant me. :) 08:13:44 Stewart Bryant Yes it is a
re-introduction of IP source routing 08:13:48 BEHCET SARIKAYA Thanks @Stewart
08:14:58 Boris Khasanov Agree with Acee 08:16:00 Cheng Li Good to hear this
topic, and happy to see more people are interested in this scenarios. We posted
an IPv6-based Cloud-oriented Networking draft one year ago, which describes the
same thing with IPv6 layer solution,
https://datatracker.ietf.org/doc/html/draft-li-rtgwg-ipv6-based-con-01 08:25:39
again! Good to see the draft @sheng liu @haomian zheng 08:26:10 Haomian Zheng
Thank you Cheng, looking forward to have more common approaches for
network-cloud. 08:27:26 Acee Lindem I don't see the need for a specific cloud
requirements for optical networks. 08:35:29 Wim Henderickx there was a lot some
work to update the net2cloud drafts. So they are in dormant mode afais.
08:35:58 John Scudder +1 acee 08:36:15 Wim Henderickx i also agree with acee
net2cloud should be agnostic to the technology we use 08:36:24 Acee Lindem The
only thing unique I heard required was more granularity and that is an ITU
requirement (as Deborah indicated). 08:36:39 Haomian Zheng just because
net2cloud should be tech-agnostic, we bring the optical consideration here to
check if this is useful input. 08:38:44 the objective is just to check if there
are common objectives, and the potential solution extension would belong to
ccamp (as indicated by Deborah, thanks) 08:40:39 Andrew Alston For me - either
of those 2 that aren't trying to inject even more stuff into the ipv6 address
and further pollute its semantics would be just fine 08:48:25 Steven Hartley
Maybe we can watch the video offline,
https://www.youtube.com/watch?v=M49yyJ0o5YU 08:50:10 around 4 min, is where you
see the good stuff :-) 08:50:43 BEHCET SARIKAYA my Q would be: do we need
ground stations when we have ISL? The draft is not clear on that 08:53:00 Doug
Montgomery Using ground relays for low-latency wide-area routing in
megaconstellations https://dl.acm.org/doi/10.1145/3365609.3365859 08:55:31
Stewart Bryant https://youtu.be/QEIUdMiColU 08:56:06
https://youtu.be/m05abdGSOxY 08:57:15 Mark Handley's early work on this
08:57:30 - the simulations 08:57:42 Alexander Clemm Why Manet? I don't think
there is any ad-hoc-ness in satellite networks 08:57:46 Stewart Bryant Yes, it
is the antithesis of ad-hoc 08:58:06 Jeffrey Haas I believe for the relaying
technology. 08:58:19 Stewart Bryant Rather it is rightly predictable 08:58:21
Jeffrey Haas There were some nice rtgwg/rtgarea presentations on manet over the
years. 08:58:37 perhaps the manet chairs will re-share to rtgwg so people can
review them 08:58:58 Stewart Bryant Even the ground station is highly
predictable 08:59:24 John Scudder It's largely a fixed network IN THAT you can
predict its state at any given time using an ephemeris. 09:00:01 Although
granted the uplinks are subject to atmospheric conditions. I thought Rick's
comment was right on. 09:00:39 Rick Taylor I say MANET because there is
movement - it may be predictable, but once per-complete orbit of the entire
network the topology changes. It might no be "Ad-hoc" but it is definitely
'constantly dynamic' - there are MANET protocols that work in this space, and
the WG contributors have experience in this field 09:00:40 Stewart Bryant What
no one discusses is that to get licences LI will need to be supportd 09:00:42
That means a pure space autonomous network is unlikley to get licensed 09:01:34
Alvaro Retana +1 Rick 09:01:38 Russ White MANET is largely just focused on
autonomic operation with little operator input ... the protocols there should
work fine for this application, or even BABEL 09:01:59 Alexander Clemm The
movement is entirely algorithmically predictable. There is nothing ad hoc to
account for. You can use very different mechanisms to exploit this. 09:02:21
Stewart Bryant I agree with Alex you can use an IPFRR method for when you get
purturbayions 09:03:05 purtabations 09:03:12 Rick Taylor +1 Russ. The trick
here is to avoid waiting for consensus because of the high rate of topological
change. The solution might (should) be reasonably simple, but constantly
running a LSP to maintain the routing table is not an elegant approach (even if
it has been shown possible) 09:03:27 Jeff Tantsura +1 Russ - I'd think so too
09:03:50 BEHCET SARIKAYA Manet may make sense because Manet comes into
operation when the infrastructure does not work like earthquakes, fires, etc.
so we need satellite infrastructure 09:04:06 I don't know if what I wrote makes
sense 09:04:30 Rick Taylor @Behcet - for that I suggest DTN.. 09:04:58 Stewart
Bryant ... but do not forget this will be a licensed service and in addition to
connectivity you will need to support interception. The constraints on global
radio networks tend to be different from the constraints we are used to in the
Internet 09:05:52 Rick Taylor @Stewart - I'm focussing on L3. That might be
aspirational, and the flown solutions might well be entirely proprietary, but
if the IETF wishes to spend cycles on this problem, I think MANET has the
correct density of expertise 09:07:07 Stewart Bryant Equally there will be
politically embargoes paths of the sort that the operator community address,
but the protocol engineers tend to ignore. 09:07:19 Rick Taylor Above the
Karmen line (100km) is the same as International Waters under a UN resolution
from 1970s. Most states with an issue with that resolution do not have the
launch capability to go against it. 09:09:19 Cheng Li BSID is only a SID, it
will be forwarded following the SFP. 09:15:34 Lin Han @Rick I have check the
MANET to see how much overlapped area of the problems and possible solution.
09:16:42 Cheng Li But PPR ID will indicate to forward the packet follow a TE
path, since the forwarding actions will be configured all the nodes along the
path. Like RSVP-TE. Get the per-path state back to the intermedia nodes
09:16:51 BEHCET SARIKAYA @Stewart: good work, good presentation 09:17:15 Cheng
Li if I get it right 09:17:17 Andrew Stone @Cheng bsid is attached to a tunnel,
and the path of that underlying tunnel can be traffic engineered, not just
shortest path 09:18:42 Shunwan Zhuang It introduces the state per ppr-id per
node ? 09:19:19 Cheng Li that TE path will be specified by the SID list after
the BSID is processed by the node which allocates the BSID. 09:19:34 Tony
Przygienda link-state ethernet? I'm "trill"'ed ;-) 09:20:10 Ketan Talaulikar So
get rid of RSVP-TE and put more state that it did into IGPs? Doesn't seem
scalable to me. 09:20:14 Jeffrey Haas seems a state trade-off. link state gets
more noise. doesn't mean state in the nodes themselves in quite the same way as
rsvp 09:21:12 Tony Przygienda paper tigers scale indefinitely, are infinitely
cheap and really, really simple ... 09:21:17 Tarek Saad related to PPR
https://datatracker.ietf.org/doc/draft-saad-teas-rsvpte-ip-tunnels/ 09:21:22
Tony Przygienda the moment you garbage can your IGP the results tend to be
mediocre since IGPs are stressed eough as they are just to make sure you can
get from A to B and not loose traffic when the network hick-ups ;-) 09:22:07
BEHCET SARIKAYA Don't understand how my chat message gets into the meeting
minutes? 09:22:57 Jeff Tantsura @jie - you could ask your question here
09:23:25 Yingzhen Qu @BEHCET SARIKAYA, we copy the chat history into minutes.
any comments? 09:24:02 Ketan Talaulikar Flooding reduction does not reduce
LSDB. 09:24:12 John Scudder @behcet you want your chat comment in the meeting
minutes? Best way to be sure is go put it there, it is a shared docuemnt.
09:24:15 (note taking tool is accessible using the icons in the upper right of
the meetecho screen -- third icon, box-with-pencil) 09:25:53 Adrian Farrel The
chat is archived, and it is not the same as the minutes. If we all go and write
random stuff in the etherpad it loses all value as a record of the decisions
made in the meeting 09:26:26 Jeffrey Haas IMO, important comments are worth
repeating on the WG mail list. That is archived, and provides a way for others
to respond. 09:27:33 John Scudder Well, different groups have different
approaches to substantive comments made in chat. It's hardly unknown for them
to be included in the minutes, nor is it inappropriate. Nor is it either
unknown or inappropriate for people to make sure their comments are reflected
accurately in the minutes (regardless of medium the comments were made in).
09:27:40 Yingzhen Qu Usually I copy the chat history and put in the minutes as
a special section 09:27:49 John Scudder nice 09:27:58 Adrian Farrel exactly
09:28:04 Jie Dong @Jeff, ok,, I was to ask about the relationship with network
slicing, but now it is ok. Rick Taylor @gyan - this is really important work.
You're right about QoS being the de-facto alternative 09:33:08 Shuping Peng
@Rick, thank you for your interest and support of the work! You can find more
information in this wiki https://datatracker.ietf.org/wg/apn/about/ 09:39:52
more archived materials can be found here: https://github.com/APN-Community
BEHCET SARIKAYA @Qu you may do anything you like, you are the chair 09:42:17
Linda Dunbar @John Scudder: I have incorporated many comments into the Etherpad
notes under their discussion topics 09:47:44 Gyan Mishra @Rick, Thank you. Yes
QOS has been the defacto standard for decades and it will be around I think
forever for IP SLA. What APN does is quite unique as it takes QOS and Diff-Serv
TE etc to the next level being able to classify traffic with flow based
granularity which fits perfect into SR intent based stateless architecture
where micro and macro steering can now occur at the APN head end mapping flows
to discrete SR-TE instantiated paths. This avoids any hardware DPI and would
provide more efficient use of hardware resources as the APN ID is in the outer
payload encapsulation so don't have to go deep into the payload for
classification / path instantiation as well as for IOAM for example
classification / path instantiation. Thank you 09:47:51 Eduard V HPCC draft
expired. 09:50:35 Jeff Tantsura @EV - this is IRTF draft 09:51:08 Rick Taylor
@Gyan - thanks - I do understand. Annoyingly I have had to use custom IP option
headers within my private networks to achieve the same thing for years. It will
be great to see this standardised and then I can drop my hacks. 09:51:34 Gyan
Mishra @Rick, Excellent and many thanks for your support on this work. 09:52:33
Rick Taylor @chairs - really good agenda this time - lot's of interesting
subjects. Thank you! 09:54:26 Jeff Tantsura @rick - doing our best ;-)

Eduard V
HPCC is the science - it is not possible to understand in the format of I-D
presentation. Deep dive is needed.