今日共有8篇文稿更新,涉及4个area里的6个WG

OPS

opsawg

1. draft-llg-opsawg-ipfix-over-quic-00

  • Title: IPFIX Protocol over QUIC
  • Authors: Yisong Liu(liuyisong@chinamobile.com), Changwang Lin(linchangwang.04414@h3c.com), Thomas Graf(thomas.graf@swisscom.com)
  • Summary: 本文主要介绍了IPFIX协议在QUIC传输协议上的实现。QUIC是一种基于UDP的多路复用和安全传输协议,它提供了可靠的、抗拥堵的连接机制,并且支持多个并发流以提高效率和性能。IPFIX协议提供了一种将流量信息从出口过程传递到收集过程的方法。本文详细描述了如何使用QUIC作为IPFIX协议的传输协议,包括连接建立、连接终止以及多流使用等。此外,还讨论了端点认证、操作考虑、IANA考虑等内容。总之,本文为使用QUIC作为IPFIX协议的传输协议提供了详细的指导。

RTG

ccamp

1. draft-ietf-ccamp-actn-optical-transport-mgmt-02

  • Title: Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks
  • Authors: Yanxia Tan(tanyx11@chinaunicom.cn), XingZhao(zhaoxing@caict.ac.cn), Chaode Yu(yuchaode@huawei.com), Daniel King(d.king@lancaster.ac.uk), Adrian Farrel(adrian@olddog.co.uk)
  • Summary: 本文主要讨论了如何在光网络中集成配置和管理,即Abstraction and Control of Traffic Engineering Networks (ACTN)系统中的组件。它介绍了如何在现有IETF工作基础上实现FCAPS能力,以及需要新工作的范围。该文稿还详细描述了这些改进后的ACTN架构,并提出了相应的可互操作性和兼容性考虑,以确保系统的稳定运行。 文中还对FCAPS与光网络的具体应用进行了分析,指出它们之间的差异,并提出了一种新的融合方法来提供光网络管理和控制功能。此外,文稿探讨了安全性的要求,强调了在网络基础设施中的重要性。最后,文稿总结了本文的核心思想,并提供了未来可能的工作方向。 总的来说,本文深入研究了如何将现有的技术应用于光网络中,以实现更好的管理和控制。它为未来的光网络发展指出了明确的方向,并且对未来的技术进步做出了展望。
  • Diff: 新版本的英文标准文稿(RFC8453)在保留了ACTN架构的基础上,增加了对故障、配置、会计、性能和安全(FCAPS)等网络管理功能的支持。这使得该架构可以更有效地管理和控制网络资源,满足特定服务或应用的需求。 相比旧版本的英文标准文稿,新版本的主要区别在于: 1. 引入了FCAPS功能支持,即故障、配置、会计、性能和安全(FCAPS)功能,以提供精细网络管理功能,从而更好地协调和运营光网络。 2. 提出了细粒度网络管理的概念,强调通过抽象化和细化技术来实现。 3. 提出了新的数据模型,如网络设备、逻辑对象和连接等,并将其与现有的YANG模型相结合,以增强细粒度网络管理能力。 4. 提出了未来可能需要的新工作,以补充现有模型。 这些变化使得新版本的ACTN架构更具灵活性和可扩展性,能够应对更多复杂的技术挑战,更好地服务于光网络业务需求。

idr

1. draft-ietf-idr-bgp-ls-sr-policy-09

  • Title: Advertisement of Segment Routing Policies using BGP Link-State
  • Authors: Stefano Previdi(stefano.previdi@gmail.com), Ketan Talaulikar(ketant.ietf@gmail.com), Jie Dong(jie.dong@huawei.com), Hannes Gredler(hannes@rtbrick.com), Jeff Tantsura(jefftant.ietf@gmail.com)
  • Summary: 这篇文档提出了一个机制,用于收集和发布网络管理系统(NMS)对段路由(SR)政策的状态信息。该策略在管理型多区域或多自治系统(AS)环境中使用,以获取全局视图。此外,它还描述了如何利用BGP和其扩展功能来支持外部组件通过BGP-LS协议获取SR政策状态信息。 文中定义了两个关键概念:SRPolicy候选路径(CP)和SRBindingSID(BSID)。SRCP是SR Policy的子集,BSID是其操作属性。BSID可以由头端节点生成,并且可以在多个实例上出现,以便报告不同子集的信息。 文档还详细描述了各种TLVs,包括SRBindingSID、SRv6BindingSID、SRCPState、SRPolicyName等,它们分别承载了不同级别的状态信息。这些TLVs都是可选的,并且需要特定的参数来表示当前的状态。 最后,文稿讨论了安全性考虑,如加密传输、身份验证、访问控制等问题,以及与IPSec、IKE、ISAKMP等安全协议的兼容性。同时,也提到了可能的安全问题,例如明文传输导致的安全风险。 总的来说,这篇文档提供了实现SRPolicy状态收集和发布的一种新方法,为基于BGP的SRPolicy状态交换提供了一个框架,有助于改善SRPolicy的状态维护和优化网络资源。
  • Diff: 该文档描述了一种机制,用于收集端节点本地可用的段路由政策信息,并将其发布到BGP链路状态(BGP-LS)更新中。这种信息可用于外部组件进行路径计算、重新优化、服务放置等操作。 主要内容如下: 1. 定义了新的BGP-LS NLRI类型,即SR Policy候选路径NLRI,用于报告单个SR Policy候选路径的信息及其关联的段列表。 2. 定义了SR Policy候选路径描述符TLV,标识一个段路由策略候选路径。 3. 定义了SR Policy状态TLV,这些TLV在BGP-LS中与SR Policy候选路径NLRI一起携带,用于报告端节点本地可用的段路由政策状态。 4. 提供了详细的广告流程和管理性考虑因素,以及IANA资源分配信息。 相比于旧版本,新版本的主要区别在于: 1. 使用了更符合标准的语言来定义不同的TLVs,例如添加了协议起源字段和属性标志位,以提供更多的语义支持。 2. 新增了SRv6 Binding SID TLV,为SRv6绑定SID提供了单独的TLV,可以单独报告。 3. 改进了SR Policy状态TLV的结构和使用方式,增加了更多子TLV,以支持更多功能需求。 4. 提供了对协议起源代码点的支持,以便更好地控制SR Policy的状态传递过程。 5. 提出了对一些子TLV的定义,如SR Affinity Constraint Sub-TLV、SR SRLG Constraint Sub-TLV等,以支持SR Policy的动态配置。 总的来说,新版本引入了许多创新的功能特性,使段路由政策能够更加灵活地被外部系统接收和利用。

nvo3

1. draft-ietf-nvo3-geneve-oam-13

  • Title: Active OAM for use in GENEVE
  • Authors: Greg Mirsky(gregimirsky@gmail.com), Sami Boutros(sboutros@ciena.com), David L. Black(david.black@dell.com), Santosh Pallagatti(santosh.pallagatti@gmail.com)
  • Summary: (draft-ietf-nvo3-geneve-oam-13)是关于在GENEVE网络中使用活动OAM协议的文档。文稿首先定义了活动OAM的概念,指出它们需要共享相同的命运,即OAM测试包必须与被监测的GENEVE隧道中的数据流量同步传输,并且封装OAM控制消息和数据包的路径应与数据流相同。此外,要求OAM测试包不被发送给租户系统。 然后讨论了如何使用活动OAM检测和定位故障。当一个通信问题出现在NVE设备A和C之间时,可以使用任何VNI来检测和定位问题,但为了遵守第4条的要求(不将管理VNI用于传输租户数据),建议默认值为1作为管理VNI。此外,描述了在GENEVE隧道中使用管理VNI来传递OAM测试包的场景。 最后,文稿提到了IANA、安全考虑、参考文献以及作者的信息。该文档没有提及具体的性能指标或维护措施,因此无法提供具体的实施指南。
  • Diff: 摘要 本文档概述了用于在GENEVE网络中的操作、管理与维护(OAM)协议的要求,并定义了使用IP封装的这些OAM协议。考虑了一些将OAM控制消息和数据包封装在底层网络中的要求。此外,还讨论了如何使用ICMP和UDP协议来实现这些要求。 与旧版本的主要区别在于: 1. 更多的详细描述和例子:新的文档提供了更多的例子和详细的描述来说明OAM协议的要求。 2. 概念更加清晰:文档更简洁地阐述了OAM协议的概念,使得读者更容易理解其工作原理。 3. 对特定场景的更多讨论:文档对某些场景如缺陷检测和故障定位进行了深入讨论。 4. 安全性考虑:新版本增加了关于网络安全的讨论,包括如何避免过载控制平面的问题。 5. 要求的简化:文档中的某些要求得到了简化,以便更好地适应实际应用场景。

WIT

tcpm

1. draft-boucadair-tcpm-rst-diagnostic-payload-09

  • Title: TCP RST Diagnostic Payload
  • Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Tirumaleswar Reddy.K(kondtir@gmail.com)
  • Summary: 本文提出了一种用于在网络连接发生断开时发送的信息格式,这种信息包含了解释网络连接被重置的原因的详细信息。它定义了用于标记和描述各种网络连接断开原因的一种新的通用机制,并提供了与这个机制相关的测试数据。 本文主要总结如下: 1. 提供了一个标准的、统一的、有效的RST诊断消息格式,用于在TCP连接断开时向接收端发送诊断信息。 2. 指出了使用CBOR序列化技术来编码这个消息,以及定义了一系列参数以表示不同的诊断信息。 3. 强调了通过注册这些代码到IANA管理的Registry来保持诊断信息的可用性,并指出了如何处理来自不同服务功能的消息,以及如何处理可能从供应商特定的登记册获取的数据。 4. 提到了一些安全考虑,如限制诊断消息大小以减少泄露隐私信息的可能性,避免在诊断消息中包含恶意文本等。 5. 阐述了实现者可以采取的措施,如在维护专门的供应商特定登记册时,应优先选择由IANA维护的现有代码,或者直接将新代码注册为IANA的已知代码。
  • Diff: 新的文档详细描述了在TCP连接断开时返回的一种诊断格式,该格式用于分享导致TCP连接被重置的原因信息。与之前的文档相比,这个新版本的主要区别在于: 1. 使用了Concise Binary Object Representation(CBOR)序列化语法来表示RST诊断payload。 2. 支持将RST诊断码映射到一个可用的注册表(例如IANA-maintained的“TCP Failure Causes”注册表组),以允许添加新代码,并保留现有代码。 3. 针对防止泄露隐私信息进行了改进,如不使用包含诸如"用户X重置明确的连接"这样的恶意消息的"reason-description"字符串。 4. 控制了可接受诊断数据包大小,建议限制为255个字符。 5. 对于通过服务功能发送的诊断消息,增加了支持逻辑。 总的来说,新的文档提供了一个更简单的方法来共享导致连接断开的原因信息,从而有助于网络端点和应用程序更好地理解和解决故障情况。

IRTF

nmrg

1. draft-irtf-nmrg-ai-challenges-04

  • Title: Research Challenges in Coupling Artificial Intelligence and Network Management
  • Authors: Jérôme François(jerome.francois@uni.lu), Alexander Clemm(ludwig@clemm.org), Dimitri Papadimitriou(dimitri.papadimitriou@alcatel.be), Stenio Fernandes(stenio.fernandes@ieee.org), Stefan Schneider(stefanbschneider@outlook.com)
  • Summary: 本文提出了网络管理(NM)中的几个挑战,这些问题与人工智能(AI)技术结合时可能会产生更有效的解决方案。主要挑战包括:大规模问题空间、不确定性以及复杂度高的问题、时间限制下的约束和资源限制等。 此外,还讨论了如何更好地利用现有数据集来训练AI模型,并提出了一些解决方案。最后,文稿总结了在实际应用中将AI与NM结合的优点和缺点,并指出了未来研究的方向。 总的来说,文稿强调了AI在解决NM问题上的潜力,但同时也指出其存在的挑战和限制。未来的研究应致力于克服这些挑战,以便实现AI与NM的有效集成。
  • Diff: 新的版本比旧版本更详细地介绍了网络管理(NM)中的挑战和采用人工智能(AI)的方法。它将这些问题分为几个主要类别,并讨论了如何在实际网络中使用AI来解决这些挑战。它还讨论了数据作为输入对机器学习算法的影响,以及隐私、可解释性和法律问题等AI应用时可能面临的挑战。 与旧版本不同的是,新的版本强调了AI技术和NM之间的结合,并提出了一个基于NM问题演进和现有AI解决方案性质的方法来识别和评估差距。它还提出了一种基于AI和NM相结合的方式,以提高效率并减少差距。此外,它也讨论了一些关键挑战,包括大解空间、不确定性、时间约束、数据依赖性、智能控制和接受度等。总之,新的版本提供了更全面和深入的信息,使人们能够更好地理解如何利用AI技术来解决NM中的挑战。

Unknown

Unknown

1. draft-storey-smtp-client-id-18

  • Title: SMTP Service Extension for Client Identity
  • Authors: William Storey(william@linuxmagic.com), Deion Yu(deiony@linuxmagic.com), Shaun Johnson(shaun@linuxmagic.com)
  • Summary: 是互联网工程任务组发布的一篇关于SMTP服务扩展的文稿。该文档主要介绍了在SMTP协议中引入一种新的身份标识方法——客户端识别(CLIENTID),使得SMTP客户端能够提供一个附加的身份令牌,用于与SMTP服务器交互。这种新方法可以提高安全性,并允许用户使用不同的设备访问同一邮箱地址。 具体来说,本文讨论了CLIENTID如何工作,包括其定义、支持条件和操作方式等。此外,还分析了CLIENTID可能的应用场景以及它如何帮助提高电子邮件安全性的概念。最后,文稿对未来的考虑、实现的限制以及可能出现的问题进行了总结。总的来说,该文档旨在解决现有SMTP协议中的安全问题,通过引入一种新的身份标识方法来增强邮件系统的安全性。
  • Diff: 这是一篇新的英文标准文档,主要内容是定义了一个名为“CLIENTID”的扩展,用于提供一个额外的身份令牌来代表SMTP客户端,以增加其对服务器的信任度。这个身份令牌可以与现有的身份验证机制相结合,为客户提供额外的安全性。 与其他身份验证方法不同的是,此扩展允许使用带有绝对自信的可靠性来访问和验证SMTP服务。在没有恶意攻击的情况下,它还可以帮助保护用户的隐私免受滥用。 尽管有多种解决方案可用,但本文档定义了客户标识扩展,并提出了一种基于客户端信息的新方式来增强认证过程中的安全性和可靠性。


2. draft-yu-imap-client-id-13

  • Title: IMAP Service Extension for Client Identity
  • Authors: Deion Yu(deiony@linuxmagic.com), Shaun Johnson(shaun@linuxmagic.com)
  • Summary: 本文主要讨论了在互联网电子邮件协议IMAP中引入一个额外的身份标识令牌(CLIENTID)的概念。这个概念允许客户端提供附加的身份信息,以便服务器可以进一步验证身份以提高安全性。文稿详细解释了这个扩展的概念和功能,并提供了具体的实现细节。此外,还讨论了一些实施和保护这种机制可能面临的挑战。 总结:本文提出了在IMAP服务中引入一个额外的身份标识令牌(CLIENTID)的概念,以增加用户的身份认证安全性和可靠性。通过这种方式,即使用户的授权信息被泄露,客户端也可以为用户提供更多的安全保障。然而,这也带来了许多技术问题,如如何有效地处理和管理这种新类型的信息,以及如何防止恶意攻击者利用这种新的身份识别方式来获取更多敏感信息。未来的研究方向包括进一步完善和标准化这些系统,同时探索如何更安全地存储和使用这些信息,避免它们被滥用或被盗用。
  • Diff: 新的版本详细描述了在互联网消息访问协议(IMAP)服务中引入客户端身份扩展的概念。这个扩展允许客户端向服务器提供一个额外的身份令牌,用于识别客户端和提供附加的安全策略。 相比于旧版,主要区别如下: 1. 更清晰地定义了客户端身份类型,并建议使用诸如UUID、LICENSE、DEVICE_ID等更明确的名称来区分不同类型的客户端身份。旧版没有提供这种建议。 2. 提供了一种更通用的方式处理客户端身份信息,例如将其存储在IMAP会话或系统日志中,而不强制使用特定的存储方式。旧版可能仅支持一种方法。 3. 强调了安全措施的重要性,指出尽管可以采用不同的客户端身份类型,但应谨慎选择以防止个人隐私泄露。 4. 支持多样的客户端身份类型,如设备标识符、软件许可证和Cookie等,为未来提供更多的定制选项。 总的来说,新的版本更加关注客户端身份的透明性和可扩展性,以及如何利用其提供的额外安全性特征。它还强调了对用户行为的监控和审计,以提高网络防御能力。