Subject: [Srcomp] Meeting today

From: chengweiqiang <[email-masked]>
Date: Fri, 30 Oct 2020 10:05:10 +0800 (CST)

As previous discussion, We will have additional meeting today. Darren,could we use the same webex link?---原始邮件---  发件人: Ron Bonica   发送时间:  2020-10-30 00:33:59 收件人:  "[email-masked]"  主题: [Srcomp] Document introduction      	p.MsoNormal, li.MsoNormal, div.MsoNormal { 	margin: 0.0in 	font-size: 11.0pt 	font-family: Calibri , sans-serif } p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph { 	margin-top: 0.0in 	margin-right: 0.0in 	margin-bottom: 0.0in 	margin-left: 0.5in 	font-size: 11.0pt 	font-family: Calibri , sans-serif } span.EmailStyle17 { 	font-family: Calibri , sans-serif 	color: windowtext } *.MsoChpDefault { 	font-family: Calibri , sans-serif } div.WordSection1 { 	page: WordSection1 } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } * { } ol { 	margin-bottom: 0.0in } ul { 	margin-bottom: 0.0in } Folks, I strongly object to the introduction as it is currently written and propose the following text.                                                                Ron  Text==== Segment Routing (SR) [RFC 8402] can be implemented over MPLS [RFC 3031] or IPv6 [RFC 8200]. When SR is implemented over MPLS, it is called SR-MPLS [RFC 8660]. When SR is implemented over IPv6, itI is called SRv6 [I-D.ietf-spring-srv6-network-programming]. SRv6 relies on an IPv6 Routing header, called the Segment Routing Header [RFC 8754]. The Segment Routing Header includes: A preamble - 8 octetsA Segment Identifier (SID) List - 16 bytes per SIDOptional TLVs SRH overhead can be excessive when an SR path contains many SIDs. Therefore, a compression mechanism is required. The SPRING WG has commissioned a design team to produce the following: A document that specifies functional requirements for the compression mechanism.A document that analyses candidate compression mechanisms in light of functional requirements. This document specifies functional requirements for the compression mechanism. A functional requirement describes an compression mechanism capability that can be observed by a network operator. For this reason, functional requirements are sometimes called “operator requirements”. This document excludes architectural requirements. An architectural requirement describes the protocol machinery that an implementation uses to satisfy a functional requirement. While protocol machinery may be visible to a network operator, it is not the operator’s primary concern. For this reason, architectural requirements are sometimes called “vendor requirements”. Because this document focuses on functional requirements, and excludes architectural requirements, it is neutral with regard to candidate solutions. It does not prefer one solution over another because it employs preferred protocol machinery. This document divides functional requirements into the following categories:Efficiency and performanceFunctional requirementsOperational requirementsScalability requirementsConvergence requirementsSecurity requirementsFor each requirement, a description, rationale and metrics are offered.    Juniper Business Use Only