* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rtgwg Status Pages

Routing Area Working Group (Active WG)
Rtg Area: Alvaro Retana, Martin Vigoureux, John Scudder | 2004-Feb-19 —  
Chairs
 
 


IETF-112 rtgwg minutes


Minutes

minutes-112-rtgwg-00 minutes



          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.
          
          



Generated from PyHt script /wg/rtgwg/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -