Minutes IETF110: rtgwg
minutes-110-rtgwg-00

IETF 110 Routing Area Open Meeting (rtgarea)
Joint with RTGWG

===================================================== 

Routing Area Directors: 
     Deborah Brungard (db3546@att.com) 
     Alvaro Retana (aretana@futurewei.com) 
     John Scudder (jgs@juniper.net) 
     Martin Vigoureux (martin.vigoureux@nokia.com) 
Web: https://datatracker.ietf.org/group/rtgarea/about/ 


RTGWG Chairs:   
     Chris Bowers
     Jeff Tantsura 

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


Date: THURSDAY, March 11, 2021 
Time: 1700-1900 Session III 

              
RTG AREA Meeting

1   17:00   15m 
Administrivia:
  - Note Well 
  - Blue Sheets 
  - Agenda Bashing 
  - RTG Area Update     Routing ADs
2   17:15   35m 
WG updates:
•   PALS
•   MPLS
•   SPRING
•   DETNET
•   RAW WG Chairs
3   17:50   10m 
Open Discussion / Any other business          

******************************************************************
******************************************************************                  

RTGWG Meeting

1   18:00   10m 
Challenges for the Internet Routing Infrastructure Introduced by 
Changes in Address Semantics
https://datatracker.ietf.org/doc/draft-king-irtf-challenges-in-routing/
Adrian Farrel

Linda:    semantic address, what is it? is it still IPv4 or IPv6?
Adrian:   what we see is adding semantics to IPv6 address. we might 
          see new address space run ships in the night, but not sure 
          it's my focus beyond what happens beyond IP routing.
Linda:    what kind of semantics are you adding?
Adrian:   we're collecting proposals. we want to research around those 
          rather than pushing individual proposal.


2   18:10   30m 
Application Aware Networking (APN)
https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis
Shuping Peng
 
Linda:    one comment, in MEF SDWan project, there's a section on 
          application based segmentation. They have a use case of 
          retail payment system, that payment system can only be mapped 
          into certain topology, virtual topology, versus other 
          application can be mapped to other topologies. I think 
          that'll be very useful to use APN concepts.
Shuping:  would you please post it to mailing list?
Uma:      Thank you for the presentation. it's good to know that it 
          starts from edge device, it's not limited to any data plane, 
          correct?
Shuping:  Yes.
Uma:      multiple WGs are discussion slicing, are you touching slicing 
          issue? or just general QoE?
Shuping:  it's a general solution. Network slicing could be integrated 
          with a VPN, so mission critical traffic could be steered into
          the dedicated network slice. That could be one of the use 
          cases of APN. 
Uma:      if it's to be done in IPv6 data plane, is it going to be 
          SRv6 or other extension header?
Shuping:  If it's IPv6, we could use hop-by-hop header, destination 
          options head, SRH and SRH TLVs. All those cold be sued to 
          encapsulate this information, not new hop-by-hop header. We
          want to make the hop-by-hop header really usable for the 
          operator because it carries lots of key features and new 
          services. After presenting in V6OPS, it has been agreed by
          the community and chairs. So the problem statement has been
          agreed upon.
Zhenbin:  People in the security area and APP area are not understanding
          the uses cases that always used in the routing area. The first
          question asked is how to map to app group or user group at a 
          network edge? We can use five tuples. Second they don't 
          understand why 5 tuples can be used directly? In transport
          network, there are SRv6 tunnel, MPLS tunnel, so the five 
          tuples of the original packets is not visible in the network.
          Last question why not copy the five tuple information?
Kausik Majumdar: I'm wondering how APN hdr would be integrated with 
          MPLS or IPv4 data plane.
Shuping:  that's based on solution and we'll figure out later.
Zhenbin:  Just to add a point, for MPLS, there is extension header 
          here. On Friday, there will be joint meeting to discuss extra 
          information in MPLS data plane, and we might be able to use 
          special purpose label to indicate extension information below 
          the label stack.


-----------------------------------------------------------------------

IETF 110 RTGWG Agenda – Session II
 
Chairs:    Chris Bowers
           Jeff Tantsura
Secretary: Yingzhen Qu
 
WG Page:    http://tools.ietf.org/wg/rtgwg/
Materials:  https://datatracker.ietf.org/meeting/110/session/rtgwg
 
Date: Friday, March 12th , 2021
Time: 17:00 -19:00 UTC + 1
 
1 17:00 15m 
WG update Chris/Jeff


2 17:15 15m 
The Integrated OAM
https://datatracker.ietf.org/doc/draft-mmm-rtgwg-integrated-oam/
Greg Mirsky

Rakesh Gandhi: there is a similar draft in BFD, is it related?
Greg:       this one replaced that draft.
Rakesh Gandhi: it was not clear combining RFC 6374 and BFD, what 
            requirements are addressed. It was discussed in BFD WG.
Greg:       First to reduce number of OAM protocols need to be 
            supported. Second is to make it light weight. BFD runs at 
            hight interval rate, but the performance measurement 
            doesn't need high rate. The draft has more details of 
            motivations. Protocol like RIFT, already provides infra 
            supports that continuity. It might be nice feature to 
            complement it with the performance monitoring.
Rakesh:     there is work in SPRING going on. we need to compare with 
            other work in other WGs.
Greg:       I know you're referring to SR PM work, it's too heavy for 
            continuity. It was not designed at high rate, like 3.3 ms. 
            We're proposing different approach to this problem. what 
            we're doing is try to solve it differently. There is real 
            need to have integrated OAM work. Let's discuss more on 
            which approach is more realistic.
Cheng Li:   Do you want to extend BFD?
Greg:       what we're proposing here won't be on top of BFD, more for 
            a new protocol inheriting the best features of BFD, like 
            negotiation. This is not extended BFD, to remove confusions, 
            we marked this draft as replacement of the extended BFD 
            draft. The resulting protocol will be similar to BFD, but 
            not extension to BFD.
Cheng Li:   we have another proposal that will be presented later.
Ville Hallivuori: you have this algorithm of negotiation for security 
            and that's about a decade old. The draft says you don't 
            have authentication.
Greg:       we appreciate comments and open to suggestions. We can 
            discuss more on the list. Different node can be upgraded 
            at different level is more flexible approach. Your 
            suggestion of mandatory security probably the right way. 
            We need to understand more.
Jeff Hass:  as BFD chair, It's worth noting that we had long 
            conversations with Greg, about could we put this inside of 
            BFD. his slides makes a good point that what we're doing 
            is we're leveraging BFD like mechanisms, the properties 
            that are sort of liked BFD is being able to carry out 
            information from one system to another in a periodic 
            fashion. We do know that BFD is capable of doing that in 
            terms of its protocol machinery, but we're sort of diluting 
            the core mission of BFD in terms of providing continuity 
            checks at speed. So we did suggest that Greg actually 
            leverage the mechanisms from the BFD for those new 
            mechanism. So, some extent to answer Fan/s question in the 
            queue, we did discuss putting this in the BFD, it's not a 
            great fit. At least in terms of the core protocol. but 
            we're quite happy to see the mechanism that the BFD has 
            popularized carried it to the rest IETF for other purposes.
Fan Yang:   I see you mention path MTU monitoring here, is it any use 
            case for using OAM to do path MTU discover and monitoring?
Greg:       normally this is part of OAM functionality. For example, 
            MTU discovery in BIER that uses LSP ping extension. it 
            could be done on demand or periodically. in BFD, there is 
            demand from operator to monitor MTU. I do believe MTU 
            discovery is part of OAM responsibility. 
Fan:        since you mentioned BIER, what data plane do you plan to 
            use this integrated OAM?
Greg:       appreciate this question. our goal is first to define the 
            protocol, then make it applicable to all data planes. Like 
            BFD supports all sorts of data planes.
Rakesh Gandhi: One comment is that with automation and controller, and 
            SDN are fairly advanced these days. The we are doing less 
            and less control plane tunneling and extensions to simplify 
            the control plane. So I think the simple SDWAN is a perfect 
            example of how controller can be used for such use cases. 
            So here in this signaling extensions going in a different 
            direction.
Greg:       I don't believe so. I don't see that there is anything 
            precluding to have Yang data model for integrated OEM 
            protocol, and then use a centralized controller to 
            instantiate test sessions, whether pre active or on demand 
            as operator desire. so I don't see any contradiction. Let's 
            take it to the list.
Jeff T:     the questions, especially with regards to BFD extensions, 
            please send to the list, and Greg would be addressing them.

From Chat:
Rakesh Gandhi
Not sure how this draft: 
https://www.ietf.org/archive/id/draft-mmm-rtgwg-integrated-oam-00.txt 
-> relates to this draft in BFD WG. 
https://tools.ietf.org/html/draft-mirmin-bfd-extended-03
Fan Yang
why not extension on BFD, I couldn't get it.
Jeff Tantsura
@Fan - please send your q to the list
Jeffrey Haas
Jeff T, I'd be speaking to that in my comments if I get mic time.
Fan Yang
I suppose we should have enough time in this session, so a little bit 
long q is OK :-)
Rakesh Gandhi
Seems like combine BFD and RFC6374 to create a new BFD+ protocol
Jeff Tantsura
Thanks Jeff
Jeffrey Haas
When protocols become popular, people want to extend them. Sometimes 
the extensions are good fits, sometimes not. But it's good to leverage 
ideas elsewhere even if you don't put it into the same protocol.
See for example various efforts to put stuff in DNS, BGP, etc.
Tony Przygienda
Curse of success ;=)
John Scudder
There's always the tension between dump truck protocols vs cut-and-paste 
protocols.
See also the microservices pendulum.
Jeffrey Haas
Indeed. Greg now perhaps inherits the dump truck keys.
John Scudder
Complexity will get its pound of flesh no matter what we do.
Jeffrey Haas
The question now moves from "what is so important that you want to 
hear every 3.3ms" to "here's interesting stuff in a periodic basis 
that you do want to hear - now how to do we pick our timers for that?"
Jie Dong
Comparing to existing BFD + RFC6374, what is the benefit of this?
Jeff Tantsura
Jie - please send to the list
Tony Li
@jgs No, we fight it. Forever.
Jie Dong
ok
Jeffrey Haas
Eternal disappointment
Jeff Tantsura
life isn't fair...
John Scudder
@tli, sorry for the defeatist formulation. There's probably a gif from 
Braveheart that would apply here.
Russ White
state, optimization, surfaces ... choose two


3 17:30 15m 
Data Discovery Use Cases
https://datatracker.ietf.org/doc/draft-mcbride-data-discovery-use-cases/ 
Mike McBride

Joel Halpern: This is confusing. There's already a proposal for how to 
            do SFC service function discovery if you're using 
            distributed system, but it's aimed at make sure that the 
            classifier know where the SF are. Fundamentally SFC is 
            designed for cases where the application, external for 
            classifier function is not choosing the service function. 
            And there are controllers can discover the service 
            functions. This problem is well attacked, I have trouble 
            with this example.
Mike:       you can have a controller taking care of it. If there is 
            already solutions, that's great. Is that you're saying this 
            particular application has already been solved.
Joel Halpern: It doesn't need a whole new tack on the problem.
Jim Guichard: I'm aware of the service function discovery document. 
            This is just a example what kind of data we're talking 
            about. SFC is obviously one of those, it gives a picture a 
            particular data store and we'd like to be able to 
            dynamically discover it.
Joel Halpern: I get the general need to discover functions, whether 
            that falls into IETF is a whole different debate. SFC is 
            just a bad example, I'm not objecting the underlying 
            problems that Mike is talking about.

Jeff T:     Speaking as WG chair. This seems to be ocean boiling. do 
            you plan to narrow down your use cases to identify 
            consumer, publishers and how it's relevant to routing in 
            general.
Mike:       Yes, the next step is to consider the solution part of it, 
            maybe a particular use case.  at the end of this ietf we'll 
            try to satisfy a particular problem that we've identified.
Jeff T:     You should narrow down your problem statement, and make it 
            routing related.
Mike:       understood. we're gonna think about what solution might 
            solve one of these problems and that will help us narrow 
            down the scope. So yes, we'll narrow it down.
Jeff Hass:  this is boiling very large ocean. but the two general 
            notions that I think are the interesting ones. you're 
            looking at a general directory/Discovery Service to figure 
            out what are the interesting things I want to get. And over 
            your use cases you're getting the once I've decided that 
            I'm interested in something, how do I actually get it in 
            an efficient fashion that makes sense with the data. Is it 
            something that needs to be reliable? Is it something that 
            I'm willing to get periodic unreliable telemetry stream for, 
            and certainly the second piece of things is for IETF has 
            no good technologies for that sort of thing. We don't 
            really have the sort of dump truck subscription directory. 
            A thing from past history that I have exposure to is corba, 
            where you have basically objects of the system that you 
            may want to get state for and a directory mechanism was 
            created to get to the stuff and published have such things. 
            So I think that directory stuff may or may not itself be 
            within the context of IETF. The other items you have to 
            decide what the properties are you want and decide if you 
            actually have good distribution mechanisms that are fits 
            for technologies we already have.


4 17:45 15m 
Associated Channel over IPv6
https://tools.ietf.org/html/draft-yang-rtgwg-ipv6-associated-channel-00
Fan Yang

Greg:       it looks like a combination of two processes. one is error 
            detection end to end, second is protection switchover 
            coordination using remote defect indicator, this is not a 
            new problem. This has been solved using combination BFD 
            and protection control automation protocol. Another
            question, UDP is becoming predominant transport, why not 
            use UDP? why IP?
Fan:        If it's only signal degradation, BFD can't detect it 100%. 
Greg:       it's great you mention this scenario. You can look at 
            drafts in IPPM that address your scenario, how network 
            failure, packet loss and delay can be combined together.
Fan:        let's take it to the list and discuss more.


From Chat:
Tony Li
And now... we recreate FTP!
Cheng Li
Hi Tony, can you explain more? why this is similar to FTP?
Tony Li
FTP has a separate control connection.
It's a huge security problem.
Cheng Li
oh?
any link?
Tony Li
Specifically for firewalls....
Cheng Li
really good input, many thanks
Tony Li
https://tools.ietf.org/html/rfc959
Cheng Li
thanks, will go to know what is the security issues and other issues 
of FTP
Joel Halpern
@ChengLi the short version is that in order to get FTP through a 
firewall (or any security appliance really) the firewall has to examine 
the FTP control protocol payload to be able to recognize the data 
payload and allow it.
Jeffrey Haas
Similar issues exist in VOIP land.
Tony Li
Out of band control and management is a fine idea, but how do you 
securely associate the control/management connection with the data flow?
Jeffrey Haas
Especially if you need the data and control channels to share 
forwarding fate
Cheng Li
cool. It seems like this is a common issue.
It may be worthy to address
Fan Yang
would it be better if the control message is carried with the data? 
ACH is in the IPv6 header, user data is in the payload ?
Tony Li
That addresses the association issue, but adds a huge cost in overhead 
per packet.
That does nothing for other forwarding planes, also.
Tony Przygienda
There is no such thing as packet tax anymore dr li. That was atm ,=)
Tony Li
There are vendors who seem to be telling their customers that. It's a 
strategy to waste bandwidth and sell more line cards.


5 18:00 15m 
IPv6-based Cloud-Oriented Networking (CON)
https://datatracker.ietf.org/doc/draft-li-rtgwg-ipv6-based-con/ 
Cheng Li

Linda:      couple of comments. This draft covers lots of things. I 
            feel it's too big, maybe break into several drafts. For 
            example. public clouds have longer distance, and technology 
            needed for that is different from edge computing which is 
            local small domain. 
Cheng:      excellent suggestion, we'll follow up with you.
Ron Bonica: what's the ultimate goal of this draft? are you building a 
            network architecture so network operators could implement. 
            or are you suggesting the development of some new routing 
            mechanism. if the former, is RTGWG the right forum? maybe 
            ops area.
Cheng:      this is architecture draft. We're looking for gaps, we 
            need more inputs, and get new mechanism to address these 
            issues.
Ron:        question to chair or AD, is it like OPS thing?
Chris B:    we use RTGWG as open discussion platform. It has a low 
            threshold for presentations, but a significantly higher 
            threshold for adopting particular draft.
Ron:        Fair enough.
Chris:      we're not really in the context of adopting it yet.
Jeff:       try to narrow down the scope and not boil the ocean.

From Chat:
Tom Hill
Didn't flannel already implement this with VXLAN? :)
Tom Hill
'quick connect' VPNs over the Internet, between clouds
Sorry the slides moved on
I'm dual-wielding two WGs
Flannel is quite commonly used already today, AFAIK
Jeff Tantsura
flannel (or any other VXLAN overlay) just provides an overlay encap, 
nothing more
Tom Hill
Indeed, but do you need any more? Flannel went out of its way to make 
that work, without the IETF porting a protocol to 'General'/cross-Internet 
usage.
Fan Yang
@Tom will look into flannel later. But flannel can only work for VXLAN, 
there are other more IP protocols, ACH can be used for any protocols 
on IP and native IP itself.
Tom Hill
I don't see the same effort to go further than the basic VXLAN 
featureset.
Jeff Tantsura
@tom VXLAN is a L2oL3 encap and perhaps the worse choice of all the 
encaps (generic ones)
Jeffrey Haas
RFC 2549 encapsulation is perhaps worse
Cheng Li
Hi @Tom，many thanks for your input. Do you have any link of Flannel? 
Interested in it :)
Flannel is a simple and easy way to configure a layer 3 network fabric 
designed for Kubernetes.
https://machinezone.github.io/resea…etworking-solutions-for-kubernetes/
get some info from google, really helpful, will dive into it later
Tom Hill
No problem
It may not be perfect, but it is definitely in use :)
Cheng Li
https://msazure.club/flannel-networking-demystify/


6 18:15 10m 
SRv6 Midpoint Protection
https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/ 
Xuesong Geng
 
Bruno:      Speaking as spring WG chair. The scope and goal is very 
            spring specific and the mechanism is a bit heavy on SRv6. 
            In spring, we have a document with the same scope for SR 
            MPLS, so I think this draft is better to be in SPRING. I
            didn't see any email in the mailing list at spring.
Xuesong:    we're confused where to put this draft. It's been presented 
            several times, to this stage we prefer to stay in RTGWG, 
            but we're willing to present in SPRING if necessary. 
            Considering TI-LFA is here, this document is informational 
            about the forwarding behavior. we'd like to hear chair's 
            opinion.
Jeff T:     we had intentions to meet and discuss about six or seven 
            different about protections discussed between SPRING and 
            RTGWG. Let's postpone your question till we reach some 
            agreements.
Chris B:    Your work so far is still useful since most people 
            attending this meeting attending SPRING as well. It's 
            positive to have SPRING chair say that he thinks it should 
            be over in spring because at least he thinks it's 
            important work. So I wouldn't be discouraged.
Xuesong:    Happy to know that.

From Chat:
Bruno Decraene
https://tools.ietf.org/html/draft-i…g-segment-protection-sr-te-paths-00
Seem to have the same scope with the SR-MPLS data plane.