Re: [sfc] Routing Directorate Last Call Review for draft-ietf-sfc-nsh-18.txt
"Acee Lindem (acee)" <acee@cisco.com> Fri, 11 August 2017 15:59 UTC
Return-Path: <acee@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CDB13239C; Fri, 11 Aug 2017 08:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5-SlrGinbwh; Fri, 11 Aug 2017 08:59:00 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F5913235A; Fri, 11 Aug 2017 08:58:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70760; q=dns/txt; s=iport; t=1502467131; x=1503676731; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vgOv8HrqlcMfCB0ov8ZUxeCOgeITMR/8M8WIjV0Y3E4=; b=jkUjb4YcG6rOm22xcZwDaiLy9HrHHm6YoRxAzgYj1kLLfWjwuZfB934F 1b6qMdvVDBrZ7FH3XfVYUmO4Cir3XY+e7HKNAGPCYp416NF1mtK+4HX7c Rgq9EKbBbPtNQjLwlIyrFQrwhTknuJipmnKEXX1k7lxTc/Ub8zgGiN6MC E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BbAwCh041Z/40NJK1dGQEBAQEBAQEBAQEBBwEBAQEBgy0tZIEBEweDLIpdkAyBbneHP41hDoIELIE7AYNfAhqEXD8YAQIBAQEBAQEBayiFGQEFDA4BCAQNMxIQAgEGAhICBAICERUCAgIfERUCDgIEDgWKFwMVEI08nWSBbDqHMQ2EIQEBAQEBAQEDAQEBAQEBAQEBH4ELghkEgWIggy4BgnM0gleBWSsYFyiCVIJhAQSRBIcAh2Y8AodRg1OEIIR0gg9ZhQSKaIlkgk2JYQEfOIEKdxUfKoUUH4FmAXYBiSKBDwEBAQ
X-IronPort-AV: E=Sophos;i="5.41,358,1498521600"; d="scan'208";a="470361623"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Aug 2017 15:58:48 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v7BFwm5m010056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Aug 2017 15:58:48 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 11 Aug 2017 11:58:47 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 11 Aug 2017 11:58:47 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
CC: Routing ADs <rtg-ads@tools.ietf.org>, Routing Directorate <rtg-dir@ietf.org>, "draft-ietf-sfc-nsh@ietf.org" <draft-ietf-sfc-nsh@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: Routing Directorate Last Call Review for draft-ietf-sfc-nsh-18.txt
Thread-Index: AQHTErq3m3nqN4YHf0KPrcz5mpN8/w==
Date: Fri, 11 Aug 2017 15:58:47 +0000
Message-ID: <D5B34A5A.C048B%acee@cisco.com>
References: <D5B27C52.C036D%acee@cisco.com> <F405D015-E842-4C3B-BD02-35B06E56D02F@cisco.com>
In-Reply-To: <F405D015-E842-4C3B-BD02-35B06E56D02F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: text/plain; charset="utf-8"
Content-ID: <BAE4E348A654BC42B2B46554C7EB57C9@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/JBpDEH0TYLQcD7vPROmcU8_GGU8>
Subject: Re: [sfc] Routing Directorate Last Call Review for draft-ietf-sfc-nsh-18.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Aug 2017 15:59:04 -0000
Hi Carlos, On 8/11/17, 12:06 AM, "Carlos Pignataro on behalf of Carlos Pignataro (cpignata)" <cpignata@gmail.com on behalf of cpignata@cisco.com> wrote: >Hi, Acee, > >Many thanks for the thorough review! Certainly can apply this patch :-) > > The editors also acknowledge comprehensive reviews and respective >- suggestions by Med Boucadair and Adrian Farrel. >+ suggestions by Med Boucadair, Adrian Farrel, and Acee Lindem. > >It is encouraging to see that your thorough and comprehensive review >found only a handful of Minor issues, nothing Major, and nits. > >Please see inline. > > >> On Aug 10, 2017, at 9:10 PM, Acee Lindem (acee) <acee@cisco.com> wrote: >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this >>draft. The Routing Directorate seeks to review all routing or >>routing-related drafts as they pass through IETF last call and IESG >>review, and sometimes on special request. The purpose of the review is >>to provide assistance to the Routing ADs. For more information about the >>Routing Directorate, please see >>http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, >>it would be helpful if you could consider them along with any other IETF >>Last Call comments that you receive, and strive to resolve them through >>discussion or by updating the draft. >> >> Document: draft-ietf-sfc-nsh-18.txt >> Reviewer: Acee Lindem >> Review Date: August 10, 2017 >> IETF LC End Date: Not started yet. >> Intended Status: Standards Track >> >> Summary: >> I have some minor concerns about this document that I think should >>be resolved before publication. > >Thanks! Of course we will resolve. > >> It needs to be consumed along with the Service Function Chaining >>architecture. >> >> Comments: >> The document is an important piece of the Service Function Chaining >>work. I think the readability could be greatly improved with the >>editorial changes I have suggested. For example, using articles, e.g. >>“the”, when referring to the NSH. > >Yes, we will fix all nits and editorials. However, in regards to having >an article preceding “NSH” (e.g., “the NSH” or “an NSH”), I also wanted >to change that earlier when I started actively editing the document — >however I was instructed that the earlier WG consensus was to leave “NSH” >without articles. > >> >> Major Issues: N/A >> > >Ack. > >> Minor Issues: >> >> Section 1: Run-on sentense that makes up the entire third paragraph >> is too hard to parse. Please split it up and avoid >> cascading so many dependent clauses. >> >> > >OK, reworded as follows, welcome other suggestions if you have: > > New data center network and cloud architectures require more flexible > service function deployment models. Additionally, the transition to > virtual platforms demands an agile service insertion model that > supports dynamic and elastic service delivery. Specifically, the > following functions are necessary: > > The movement of service functions and application workloads in the > network. > > The ability to easily bind service policy to granular information, > such as per-subscriber state. > > The capability to steer traffic to the requisite service > function(s). This is much better. > > >> Section 2.2: The discussion of meta-data support for MD types 0x1 >>or >> 0x3 is out of context. >> > >It seems to me it is well within the context of the specification of MD >Type. Since that is an important piece of text that the WG crafted, do >you have a concrete and specific suggestion of where else in the document >it might fit better? Otherwise, I recommend leaving it as-is. Perhaps then you could add a forward reference to section. > > >> Section 2.4: The MUST's are contradictory. First it says the >>context >> header MUST be 16 bytes than it says it MUST >>be 0 bytes if >> it contains no meta-data. This is hardly >>"fixed”. > >You are mis-reading, the text tries to say that the content MBZ. Not the >length: > > When the Base Header specifies MD Type = 0x1, a Fixed Length Context > Header (16-bytes) MUST be present immediately following the Service > Path Header, as per Figure 4. A Fixed Length Context Header that > carries no metadata MUST be set to zero. > >I will reword to: > > When the Base Header specifies MD Type = 0x1, a Fixed Length Context > Header (16-bytes) MUST be present immediately following the Service > Path Header, as per Figure 4. The value of a Fixed Length Context > Header that carries no metadata MUST be set to zero. > >Better? Much better. > >> > >> Section 2.5.1: Mandating that the unassigned bit MUST NOT be set >>will >> without saying it MUST be ignored on >>receipt is >> not be backward compatible. > >OK, changed: > > Unassigned bit: one unassigned bit is available for future use. This > bit MUST be set to 0b. > >To: > > Unassigned bit: one unassigned bit is available for future use. This > bit MUST be set to 0b and MUST be ignored on receipt. Yes - except capitalize “One”. > >> >> Section 11.2.1: List the bits that are assigned. > >The whole header is not a bit mask: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >I can add the “O” bit, but otherwise those are fields and not bits. > >Happy to do this for completeness. > >OLD: > >11.2.1. NSH Base Header Unassigned Bits > > There are five unassigned bits in the NSH Base Header. New bits are > assigned via Standards Action [RFC8126]. > Bit 3 - Unassigned > Bits 16-19 - Unassigned > >NEW: > >11.2.1. NSH Base Header Bits > > There are five unassigned bits in the NSH Base Header, and one bit > assigned (O-bit). New bits are assigned via Standards Action > [RFC8126]. > > Bit 2 - O (OAM) bit > Bit 3 - Unassigned > Bits 16-19 - Unassigned Ok. > > > >> >> Section 11.2.6: MD types 1 and 2 are assigned by the document yet >> this section states that no values are >>assigned. >> > >This is about Section 2.5.1, not about MD Type. The title is incorrect. > >NEW: > >11.2.6. New IETF Assigned Optional Variable Length Metadata Type > Registry > > This document requests IANA to create a registry for the type values > owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF > Assigned Optional Variable Length Metadata Type Registry", as > specified in Section 2.5.1. > > The type values are assigned via Standards Action [RFC8126]. > > No initial values are assigned at the creation of the registry. This clears up the confusion. > > > >> Nits: > >Will take care of these nits, except “article NSH”. I think this has always been confusing in this draft since the Network Service Header is nothing more than a protocol construct in the Service Chaining Architecture. NSH is not an architecture itself. However, I’ll leave it to thew WG. Thanks, Acee > >Thanks! > >Carlos. > >> >> ACEE-M-G2HR:Desktop acee$ diff -c draft-ietf-sfc-nsh-18.txt.orig >>draft-ietf-sfc-nsh-18.txt >> *** draft-ietf-sfc-nsh-18.txt.orig >> 2017-08-04 07:27:08.000000000 -0400 >> --- draft-ietf-sfc-nsh-18.txt >> 2017-08-10 20:50:45.000000000 -0400 >> *************** >> *** 18,24 **** >> >> This document describes a Network Service Header (NSH) inserted onto >> packets or frames to realize service function paths. NSH also >> ! provides a mechanism for metadata exchange along the instantiated >> service paths. NSH is the SFC encapsulation required to support the >> Service Function Chaining (SFC) architecture (defined in RFC7665). >> >> --- 18,24 ---- >> >> This document describes a Network Service Header (NSH) inserted onto >> packets or frames to realize service function paths. NSH also >> ! provides a mechanism for metadata exchange along instantiated >> service paths. NSH is the SFC encapsulation required to support the >> Service Function Chaining (SFC) architecture (defined in RFC7665). >> >> *************** >> *** 181,187 **** >> >> Metadata: Defined in [RFC7665]. >> >> ! Network Locator: dataplane address, typically IPv4 or IPv6, used >>to >> send and receive network traffic. >> >> Network Node/Element: Device that forwards packets or frames based >> --- 181,187 ---- >> >> Metadata: Defined in [RFC7665]. >> >> ! Network Locator: Dataplane address, typically IPv4 or IPv6, used >>to >> send and receive network traffic. >> >> Network Node/Element: Device that forwards packets or frames based >> *************** >> *** 191,204 **** >> (the underlay). Packets are encapsulated or tunneled to create >> the overlay network topology. >> >> ! NSH-aware SFC-encapsulation-aware, or SFC-aware [RFC7665]. >> >> ! Service Classifier: Logical entity providing classification >> function. Since they are logical, classifiers may be co-resident >> with SFC elements such as SFs or SFFs. Service classifiers >> perform classification and impose NSH. The initial classifier >> imposes the initial NSH and sends the NSH packet to the first SFF >> ! in the path. Non-initial (i.e. subsequent) classification can >> occur as needed and can alter, or create a new service path. >> >> Service Function (SF): Defined in [RFC7665]. >> --- 191,204 ---- >> (the underlay). Packets are encapsulated or tunneled to create >> the overlay network topology. >> >> ! NSH-aware: SFC-encapsulation-aware, or SFC-aware [RFC7665]. >> >> ! Service Classifier: Logical entity providing the classification >> function. Since they are logical, classifiers may be co-resident >> with SFC elements such as SFs or SFFs. Service classifiers >> perform classification and impose NSH. The initial classifier >> imposes the initial NSH and sends the NSH packet to the first SFF >> ! in the path. Non-initial (i.e., subsequent) classification can >> occur as needed and can alter, or create a new service path. >> >> Service Function (SF): Defined in [RFC7665]. >> *************** >> *** 269,277 **** >> >> 2. Network Service Header >> >> ! NSH contains service path information and optionally metadata that >> are added to a packet or frame and used to create a service plane. >> ! An outer transport header is imposed, on NSH and the original >>packet/ >> frame, for network forwarding. >> >> >> --- 269,277 ---- >> >> 2. Network Service Header >> >> ! The NSH contains service path information and optionally metadata >>that >> are added to a packet or frame and used to create a service plane. >> ! An outer transport header is imposed on the NSH and the original >>packet/ >> frame, for network forwarding. >> >> >> *************** >> *** 282,293 **** >> Internet-Draft Network Service Header (NSH) July >>2017 >> >> >> ! A Service Classifier adds NSH. NSH is removed by the last SFF in >>the >> service chain or by an SF that consumes the packet. >> >> 2.1. Network Service Header Format >> >> ! NSH is composed of a 4-byte Base Header, a 4-byte Service Path >>Header >> and optional Context Headers, as shown in Figure 1 below. >> >> 0 1 2 3 >> --- 282,293 ---- >> Internet-Draft Network Service Header (NSH) July >>2017 >> >> >> ! A Service Classifier adds the NSH. The NSH is removed by the last >>SFF in the >> service chain or by an SF that consumes the packet. >> >> 2.1. Network Service Header Format >> >> ! The NSH is composed of a 4-byte Base Header, a 4-byte Service Path >>Header >> and optional Context Headers, as shown in Figure 1 below. >> >> 0 1 2 3 >> *************** >> *** 304,316 **** >> >> Figure 1: Network Service Header >> >> ! Base header: provides information about the service header and the >> payload protocol. >> >> ! Service Path Header: provides path identification and location >>within >> a service path. >> >> ! Context header: carries metadata (i.e., context data) along a >>service >> path. >> >> 2.2. NSH Base Header >> --- 304,316 ---- >> >> Figure 1: Network Service Header >> >> ! Base header: Provides information about the service header and the >> payload protocol. >> >> ! Service Path Header: Provides path identification and location >>within >> a service path. >> >> ! Context header: Carries metadata (i.e., context data) along a >>service >> path. >> >> 2.2. NSH Base Header >> *************** >> *** 368,374 **** >> for service plane loop detection. The initial TTL value SHOULD be >> configurable via the control plane; the configured initial value can >> be specific to one or more SFPs. If no initial value is explicitly >> ! provided, the default initial TTL value 63 MUST be used. Each SFF >> involved in forwarding an NSH packet MUST decrement the TTL value by >> 1 prior to NSH forwarding lookup. Decrementing by 1 from an >>incoming >> value of 0 shall result in a TTL value of 63. The packet MUST NOT >>be >> --- 368,374 ---- >> for service plane loop detection. The initial TTL value SHOULD be >> configurable via the control plane; the configured initial value can >> be specific to one or more SFPs. If no initial value is explicitly >> ! provided, the default initial TTL value of 63 MUST be used. Each >>SFF >> involved in forwarding an NSH packet MUST decrement the TTL value by >> 1 prior to NSH forwarding lookup. Decrementing by 1 from an >>incoming >> value of 0 shall result in a TTL value of 63. The packet MUST NOT >>be >> *************** >> *** 380,389 **** >> elements. Elements which do not understand the meaning of any of >> these bits MUST NOT modify their actions based on those unknown >>bits. >> >> ! Length: The total length, in 4-byte words, of NSH including the >>Base >> Header, the Service Path Header, the Fixed Length Context Header or >> ! Variable Length Context Header(s). The length MUST be of value 0x6 >> ! for MD Type equal to 0x1, and MUST be of value 0x2 or greater for >>MD >> Type equal to 0x2. The length of the NSH header MUST be an integer >> >> >> --- 380,389 ---- >> elements. Elements which do not understand the meaning of any of >> these bits MUST NOT modify their actions based on those unknown >>bits. >> >> ! Length: The total length, in 4-byte words, of the NSH including >>the Base >> Header, the Service Path Header, the Fixed Length Context Header or >> ! Variable Length Context Header(s). The length MUST be 0x6 >> ! for MD Type equal to 0x1, and MUST be 0x2 or greater for MD >> Type equal to 0x2. The length of the NSH header MUST be an integer >> >> >> *************** >> *** 397,431 **** >> multiple of 4 bytes, thus variable length metadata is always padded >> out to a multiple of 4 bytes. >> >> ! MD Type: indicates the format of NSH beyond the mandatory Base >>Header >> and the Service Path Header. MD Type defines the format of the >> metadata being carried. Please see the IANA Considerations >> Section 11.2.3. >> >> This document specifies the following four MD Type values: >> >> ! 0x0 - this is a reserved value. Implementations SHOULD silently >> discard packets with MD Type 0x0. >> >> ! 0x1 - which indicates that the format of the header includes a >>fixed >> length Context Header (see Figure 4 below). >> >> ! 0x2 - which does not mandate any headers beyond the Base Header and >> Service Path Header, but may contain optional variable length >>Context >> Header(s). The semantics of the variable length Context Header(s) >> are not defined in this document. The format of the optional >> variable length Context Headers is provided in Section 2.5.1. >> >> ! 0xF - this value is reserved for experimentation and testing, as >>per >> [RFC3692]. Implementations not explicitly configured to be part of >> an experiment SHOULD silently discard packets with MD Type 0xF. >> >> The format of the Base Header and the Service Path Header is >> invariant, and not affected by MD Type. >> >> ! NSH implementations MUST support MD type = 0x1 and MD Type = 0x2 >> ! (where the length is of value 0x2). NSH implementations SHOULD >> ! support MD Type 0x2 with length > 0x2. There exists, however, a >> middle ground, wherein a device will support MD Type 0x1 (as per the >> MUST) metadata, yet be deployed in a network with MD Type 0x2 >> metadata packets. In that case, the MD Type 0x1 node, MUST utilize >> --- 397,431 ---- >> multiple of 4 bytes, thus variable length metadata is always padded >> out to a multiple of 4 bytes. >> >> ! MD Type: Indicates the format of NSH beyond the mandatory Base >>Header >> and the Service Path Header. MD Type defines the format of the >> metadata being carried. Please see the IANA Considerations >> Section 11.2.3. >> >> This document specifies the following four MD Type values: >> >> ! 0x0 - This is a reserved value. Implementations SHOULD silently >> discard packets with MD Type 0x0. >> >> ! 0x1 - This indicates that the format of the header includes a fixed >> length Context Header (see Figure 4 below). >> >> ! 0x2 - This does not mandate any headers beyond the Base Header and >> Service Path Header, but may contain optional variable length >>Context >> Header(s). The semantics of the variable length Context Header(s) >> are not defined in this document. The format of the optional >> variable length Context Headers is provided in Section 2.5.1. >> >> ! 0xF - This value is reserved for experimentation and testing, as >>per >> [RFC3692]. Implementations not explicitly configured to be part of >> an experiment SHOULD silently discard packets with MD Type 0xF. >> >> The format of the Base Header and the Service Path Header is >> invariant, and not affected by MD Type. >> >> ! NSH implementations MUST support MD types 0x1 and 0x2 >> ! (where the length is 0x2). NSH implementations SHOULD >> ! support MD Type 0x2 with a length greater than 0x2. There exists, >>however, a >> middle ground, wherein a device will support MD Type 0x1 (as per the >> MUST) metadata, yet be deployed in a network with MD Type 0x2 >> metadata packets. In that case, the MD Type 0x1 node, MUST utilize >> *************** >> *** 485,503 **** >> >> The meaning of these fields is as follows: >> >> ! Service Path Identifier (SPI): identifies a service path. >> Participating nodes MUST use this identifier for Service Function >> Path selection. The initial classifier MUST set the appropriate SPI >> for a given classification result. >> >> ! Service Index (SI): provides location within the SFP. The initial >> classifier for a given SFP SHOULD set the SI to 255, however the >> control plane MAY configure the initial value of SI as appropriate >> (i.e., taking into account the length of the service function path). >> ! Service Index MUST be decremented by a value of 1 by Service >> Functions or by SFC Proxy nodes after performing required services >> ! and the new decremented SI value MUST be used in the egress NSH >> ! packet. The initial Classifier MUST send the packet to the first >>SFF >> >> >> >> --- 485,503 ---- >> >> The meaning of these fields is as follows: >> >> ! Service Path Identifier (SPI): Identifies a service path. >> Participating nodes MUST use this identifier for Service Function >> Path selection. The initial classifier MUST set the appropriate SPI >> for a given classification result. >> >> ! Service Index (SI): Provides location within the SFP. The initial >> classifier for a given SFP SHOULD set the SI to 255, however the >> control plane MAY configure the initial value of SI as appropriate >> (i.e., taking into account the length of the service function path). >> ! The Service Index MUST be decremented by a value of 1 by Service >> Functions or by SFC Proxy nodes after performing required services >> ! and the new decremented SI value MUST be used in the egress >>packet's >> ! NSH. The initial Classifier MUST send the packet to the first SFF >> >> >> >> *************** >> *** 511,519 **** >> SPI, the (re)classifier is, in effect, the initial classifier for >>the >> resultant SPI. >> >> ! The SI is used in conjunction with Service Path Identifier for >> Service Function Path Selection and for determining the next SFF/SF >> ! in the path. The SI is also valuable when troubleshooting/ >>reporting >> service paths. Additionally, while the TTL field is the main >> mechanism for service plane loop detection, the SI can also be used >> for detecting service plane loops. >> --- 511,519 ---- >> SPI, the (re)classifier is, in effect, the initial classifier for >>the >> resultant SPI. >> >> ! The SI is used in conjunction with the Service Path Identifier for >> Service Function Path Selection and for determining the next SFF/SF >> ! in the path. The SI is also valuable when >>troubleshooting/reporting >> service paths. Additionally, while the TTL field is the main >> mechanism for service plane loop detection, the SI can also be used >> for detecting service plane loops. >> *************** >> *** 603,609 **** >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ! | Metadata Class | Type |U| Len | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Metadata | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> --- 603,609 ---- >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ! | Metadata Class | Type |U| Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Metadata | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> *************** >> *** 618,643 **** >> Internet-Draft Network Service Header (NSH) July >>2017 >> >> >> ! Metadata Class (MD Class): defines the scope of the 'Type' field to >> provide a hierarchical namespace. The IANA Considerations >> Section 11.2.4 defines how the MD Class values can be allocated to >> standards bodies, vendors, and others. >> >> ! Type: indicates the explicit type of metadata being carried and is >> ! the responsibility of the MD Class owner. >> >> ! Unassigned bit: one unassigned bit is available for future use. >>This >> ! bit MUST be set to 0b. >> >> ! Length: indicates the length of the variable metadata, in single >>byte >> ! words. In case the metadata length is not an integer number of >> 4-byte words, the sender MUST add pad bytes immediately following >>the >> last metadata byte to extend the metadata to an integer number of >> 4-byte words. The receiver MUST round up the length field to the >> nearest 4-byte word boundary, to locate and process the next field >>in >> the packet. The receiver MUST access only those bytes in the >> ! metadata indicated by the length field (i.e., actual number of >>single >> ! byte words) and MUST ignore the remaining bytes up to the nearest >> 4-byte word boundary. The Length may be 0 or greater. >> >> A value of 0 denotes a Context Header without a Variable Metadata >> --- 618,643 ---- >> Internet-Draft Network Service Header (NSH) July >>2017 >> >> >> ! Metadata Class (MD Class): Defines the scope of the 'Type' field to >> provide a hierarchical namespace. The IANA Considerations >> Section 11.2.4 defines how the MD Class values can be allocated to >> standards bodies, vendors, and others. >> >> ! Type: Indicates the explicit type of metadata being carried. >>Definition >> ! of the Type is the responsibility of the MD Class owner. >> >> ! Unassigned bit: One unassigned bit is available for future use. >>This >> ! bit MUST NOT be set. >> >> ! Length: Indicates the length of the variable metadata, in bytes. >> ! When the metadata length is not an integer number of >> 4-byte words, the sender MUST add pad bytes immediately following >>the >> last metadata byte to extend the metadata to an integer number of >> 4-byte words. The receiver MUST round up the length field to the >> nearest 4-byte word boundary, to locate and process the next field >>in >> the packet. The receiver MUST access only those bytes in the >> ! metadata indicated by the length field (i.e., actual number bytes) >> ! and MUST ignore the remaining bytes up to the nearest >> 4-byte word boundary. The Length may be 0 or greater. >> >> A value of 0 denotes a Context Header without a Variable Metadata >> *************** >> *** 647,669 **** >> that are mandatory-to-implement or those that are mandatory-to- >> process. These considerations are deployment-specific. However, >>the >> control plane is entitled to instruct SFC-aware SFs with the data >> ! structure of context header together with their scoping (see >> Section 3.3.3 of [I-D.ietf-sfc-control-plane]). >> >> ! Upon receipt of a packet that belong to a given SFP, if a >>mandatory- >> to-process context header is missing in that packet, the SFC-aware >>SF >> MUST NOT process the packet and MUST log at least once per the SPI >> ! for which a mandatory metadata is missing. >> >> If multiple mandatory-to-process context headers are required for a >> ! given SFP, the control plane MAY instruct the SFC-aware SF with the >> ! order to consume these Context Headers. If no instructions are >> provided, the SFC-aware SF MUST process these Context Headers in the >> order their appear in an NSH packet. >> >> If multiple instances of the same metadata are included in an NSH >> packet, but the definition of that context header does not allow for >> ! it, the SFC-aware SF MUST process first instance and ignore >> subsequent instances. >> >> >> --- 647,669 ---- >> that are mandatory-to-implement or those that are mandatory-to- >> process. These considerations are deployment-specific. However, >>the >> control plane is entitled to instruct SFC-aware SFs with the data >> ! structure of context header together with its scoping (see >> Section 3.3.3 of [I-D.ietf-sfc-control-plane]). >> >> ! Upon receipt of a packet that belongs to a given SFP, if a >>mandatory- >> to-process context header is missing in that packet, the SFC-aware >>SF >> MUST NOT process the packet and MUST log at least once per the SPI >> ! for which the mandatory metadata is missing. >> >> If multiple mandatory-to-process context headers are required for a >> ! given SFP, the control plane MAY instruct the SFC-aware SF >> ! to consume these Context Headers. If no instructions are >> provided, the SFC-aware SF MUST process these Context Headers in the >> order their appear in an NSH packet. >> >> If multiple instances of the same metadata are included in an NSH >> packet, but the definition of that context header does not allow for >> ! it, the SFC-aware SF MUST process the first instance and ignore >> subsequent instances. >> >> >> *************** >> *** 677,693 **** >> 3. NSH Actions >> >> NSH-aware nodes are the only nodes that may alter the content of NSH >> ! headers. NSH-aware nodes include: service classifiers, SFF, SF and >> SFC proxies. These nodes have several possible NSH-related actions: >> >> ! 1. Insert or remove NSH: These actions can occur at the start and >> ! end respectively of a service path. Packets are classified, >>and >> ! if determined to require servicing, NSH will be imposed. A >> ! service classifier MUST insert NSH at the start of an SFP. An >> ! imposed NSH MUST contain valid Base Header and Service Path >> Header. At the end of a service function path, an SFF, MUST be >> ! the last node operating on the service header and MUST remove >>NSH >> ! before forwarding or delivering the un-encapsulated packet >> >> Multiple logical classifiers may exist within a given service >> path. Non-initial classifiers may re-classify data and that re- >> --- 677,693 ---- >> 3. NSH Actions >> >> NSH-aware nodes are the only nodes that may alter the content of NSH >> ! headers. NSH-aware nodes include: service classifiers, SFFs, SFs, >>and >> SFC proxies. These nodes have several possible NSH-related actions: >> >> ! 1. Insert or remove NSH: These actions can occur respectively at >>the start or >> ! end of a service path. Packets are classified, and >> ! if determined to require servicing, an NSH will be imposed. A >> ! service classifier MUST insert an NSH at the start of an SFP. >>An >> ! imposed NSH MUST contain both a valid Base Header and Service >>Path >> Header. At the end of a service function path, an SFF, MUST be >> ! the last node operating on the service header and MUST remove >>the NSH >> ! before forwarding or delivering the un-encapsulated packet. >> >> Multiple logical classifiers may exist within a given service >> path. Non-initial classifiers may re-classify data and that re- >> *************** >> *** 696,702 **** >> classification that results in a change of service path, it MUST >> remove the existing NSH and MUST impose a new NSH with the Base >> Header and Service Path Header reflecting the new service path >> ! information and set the initial SI. Metadata MAY be preserved >>in >> the new NSH. >> >> >> --- 696,702 ---- >> classification that results in a change of service path, it MUST >> remove the existing NSH and MUST impose a new NSH with the Base >> Header and Service Path Header reflecting the new service path >> ! information and MUST set the initial SI. Metadata MAY be >>preserved in >> the new NSH. >> >> >> *************** >> *** 719,725 **** >> Service Index and MAY update contexts. When an SFC proxy >> receives an NSH-encapsulated packet, it MUST remove NSH before >> forwarding it to an NSH unaware SF. When the SFC Proxy receives >> ! a packet back from an NSH unaware SF, it MUST re-encapsulates >>it >> with the correct NSH, and MUST decrement the Service Index by >> one. >> >> --- 719,725 ---- >> Service Index and MAY update contexts. When an SFC proxy >> receives an NSH-encapsulated packet, it MUST remove NSH before >> forwarding it to an NSH unaware SF. When the SFC Proxy receives >> ! a packet back from an NSH unaware SF, it MUST re-encapsulate it >> with the correct NSH, and MUST decrement the Service Index by >> one. >> >> *************** >> *** 763,778 **** >> >> 4. NSH Transport Encapsulation >> >> ! Once NSH is added to a packet, an outer encapsulation is used to >> forward the original packet and the associated metadata to the start >> of a service chain. The encapsulation serves two purposes: >> >> 1. Creates a topologically independent services plane. Packets are >> forwarded to the required services without changing the >> ! underlying network topology >> >> ! 2. Transit network nodes simply forward the encapsulated packets >>as >> ! is. >> >> The service header is independent of the encapsulation used and is >> encapsulated in existing transports. The presence of NSH is >> --- 763,778 ---- >> >> 4. NSH Transport Encapsulation >> >> ! Once a NSH is added to a packet, an outer encapsulation is used to >> forward the original packet and the associated metadata to the start >> of a service chain. The encapsulation serves two purposes: >> >> 1. Creates a topologically independent services plane. Packets are >> forwarded to the required services without changing the >> ! underlying network topology. >> >> ! 2. Transit network nodes simply forward the encapsulated packets >> ! without modification. >> >> The service header is independent of the encapsulation used and is >> encapsulated in existing transports. The presence of NSH is >> *************** >> *** 788,794 **** >> >> 5. Fragmentation Considerations >> >> ! NSH and the associated transport header are "added" to the >> encapsulated packet/frame. This additional information increases >>the >> size of the packet. >> >> --- 788,794 ---- >> >> 5. Fragmentation Considerations >> >> ! The NSH and the associated transport header are "added" to the >> encapsulated packet/frame. This additional information increases >>the >> size of the packet. >> >> *************** >> *** 806,812 **** >> >> 6.1. SFFs and Overlay Selection >> >> ! As described above, NSH contains a Service Path Identifier (SPI) >>and >> a Service Index (SI). The SPI is, as per its name, an identifier. >> The SPI alone cannot be used to forward packets along a service >>path. >> Rather the SPI provides a level of indirection between the service >> --- 806,812 ---- >> >> 6.1. SFFs and Overlay Selection >> >> ! As described above, an NSH contains a Service Path Identifier >>(SPI) and >> a Service Index (SI). The SPI is, as per its name, an identifier. >> The SPI alone cannot be used to forward packets along a service >>path. >> Rather the SPI provides a level of indirection between the service >> *************** >> *** 827,839 **** >> is incorrect and the packet must be discarded. >> >> This indirection -- SPI to overlay -- creates a true service plane. >> ! That is the SFF/SF topology is constructed without impacting the >> ! network topology but more importantly service plane only >>participants >> (i.e., most SFs) need not be part of the network overlay topology >>and >> its associated infrastructure (e.g., control plane, routing tables, >> ! etc.) SFs need to be able to return a packet to an appropriate SFF >> ! (i.e., has the requisite NSH information) when service processing >>is >> ! complete. This can be via the over or underlay and in some case >> >> >> >> --- 827,839 ---- >> is incorrect and the packet must be discarded. >> >> This indirection -- SPI to overlay -- creates a true service plane. >> ! That is, the SFF/SF topology is constructed without impacting the >> ! network topology but more importantly, service plane only >>participants >> (i.e., most SFs) need not be part of the network overlay topology >>and >> its associated infrastructure (e.g., control plane, routing tables, >> ! etc). SFs need to be able to return a packet to an appropriate SFF >> ! (i.e., one that has the requisite NSH information) when service >>processing is >> ! complete. This can be via the overlay or underlay and, in some >>case >> >> >> >> *************** >> *** 847,853 **** >> requisite connectivity. >> >> The mapping of SPI to transport occurs on an SFF (as discussed >>above, >> ! the first SFF in the path gets a NSH encapsulated packet from the >> Classifier). The SFF consults the SPI/ID values to determine the >> appropriate overlay transport protocol (several may be used within a >> given network) and next hop for the requisite SF. Table 1 below >> --- 847,853 ---- >> requisite connectivity. >> >> The mapping of SPI to transport occurs on an SFF (as discussed >>above, >> ! the first SFF in the path gets an NSH encapsulated packet from the >> Classifier). The SFF consults the SPI/ID values to determine the >> appropriate overlay transport protocol (several may be used within a >> given network) and next hop for the requisite SF. Table 1 below >> *************** >> *** 874,880 **** >> >> Additionally, further indirection is possible: the resolution of the >> required SF network locator may be a localized resolution on an SFF, >> ! rather than a service function chain control plane responsibility, >>as >> per Table 2 and Table 3 below. >> >> Please note: VXLAN-gpe and GRE in the above table refer to >> --- 874,880 ---- >> >> Additionally, further indirection is possible: the resolution of the >> required SF network locator may be a localized resolution on an SFF, >> ! rather than a service function chain control-plane responsibility, >>as >> per Table 2 and Table 3 below. >> >> Please note: VXLAN-gpe and GRE in the above table refer to >> *************** >> *** 925,934 **** >> Since the SPI is a representation of the service path, the lookup >>may >> return more than one possible next-hop within a service path for a >> given SF, essentially a series of weighted (equally or otherwise) >> ! paths to be used (for load distribution, redundancy or policy), see >> Table 4. The metric depicted in Table 4 is an example to help >> illustrated weighing SFs. In a real network, the metric will range >> ! from a simple preference (similar to routing next- hop), to a true >> dynamic composite metric based on some service function-centric >>state >> (including load, sessions state, capacity, etc.) >> >> --- 925,934 ---- >> Since the SPI is a representation of the service path, the lookup >>may >> return more than one possible next-hop within a service path for a >> given SF, essentially a series of weighted (equally or otherwise) >> ! paths to be used (for load distribution, redundancy, or policy), >>see >> Table 4. The metric depicted in Table 4 is an example to help >> illustrated weighing SFs. In a real network, the metric will range >> ! from a simple preference (similar to routing next-hop), to a true >> dynamic composite metric based on some service function-centric >>state >> (including load, sessions state, capacity, etc.) >> >> *************** >> *** 981,987 **** >> Furthermore, the SPI to overlay mapping occurs at each SFF >> independently. Any combination of topology selection is possible. >> Please note, there is no requirement to create a new overlay >>topology >> ! if a suitable one already existing. NSH packets can use any (new >>or >> existing) overlay provided the requisite connectivity requirements >> are satisfied. >> >> --- 981,987 ---- >> Furthermore, the SPI to overlay mapping occurs at each SFF >> independently. Any combination of topology selection is possible. >> Please note, there is no requirement to create a new overlay >>topology >> ! if a suitable one already exists. NSH packets can use any (new or >> existing) overlay provided the requisite connectivity requirements >> are satisfied. >> >> *************** >> *** 1025,1032 **** >> The SPI and SI serve an important function for visibility into the >> service topology. An operator can determine what service path a >> packet is "on", and its location within that path simply by viewing >> ! NSH information (packet capture, IPFIX, etc.) The information can >>be >> ! used for service scheduling and placement decisions, >>troubleshooting >> and compliance verification. >> >> 6.4. Service Graphs >> --- 1025,1032 ---- >> The SPI and SI serve an important function for visibility into the >> service topology. An operator can determine what service path a >> packet is "on", and its location within that path simply by viewing >> ! NSH information (packet capture, IPFIX, etc). The information can >>be >> ! used for service scheduling and placement decisions, >>troubleshooting, >> and compliance verification. >> >> 6.4. Service Graphs >> *************** >> *** 1092,1098 **** >> >> +-------+ +-------+ +-------+ >> | SFF )------->( SFF |------->| SFF | >> ! +---^---+ +---|---+ +---|---+ >> ,-|-. ,-|-. ,-|-. >> / \ / \ / \ >> ( Class ) ( SF1 ) ( SF2 ) >> --- 1092,1099 ---- >> >> +-------+ +-------+ +-------+ >> | SFF )------->( SFF |------->| SFF | >> ! +---+---+ +---+---+ +---+---+ >> ! ^ | | >> ,-|-. ,-|-. ,-|-. >> / \ / \ / \ >> ( Class ) ( SF1 ) ( SF2 ) >> *************** >> *** 1135,1141 **** >> +---+---+ employees >> | | >> +-------+ >> ! external >> system: >> Employee >> AppZ >> --- 1136,1142 ---- >> +---+---+ employees >> | | >> +-------+ >> ! External >> system: >> Employee >> AppZ >> *************** >> *** 1151,1157 **** >> considerations may need to be considered. For example, if the >> metadata conveys tenant information, that information may need to be >> authenticated and/or encrypted between the originator and the >> ! intended recipients (which may include intended SFs only) . NSH >> itself does not provide privacy functions, rather it relies on the >> transport/overlay layer. An operator can select the appropriate >> transport to ensure confidentially (and other security) >> --- 1152,1158 ---- >> considerations may need to be considered. For example, if the >> metadata conveys tenant information, that information may need to be >> authenticated and/or encrypted between the originator and the >> ! intended recipients (which may include intended SFs only). The NSH >> itself does not provide privacy functions, rather it relies on the >> transport/overlay layer. An operator can select the appropriate >> transport to ensure confidentially (and other security) >> *************** >> *** 1161,1169 **** >> 7.2. Updating/Augmenting Metadata >> >> Post-initial metadata imposition (typically performed during initial >> ! service path determination), metadata may be augmented or updated: >> >> ! 1. Metadata Augmentation: Information may be added to NSH's >>existing >> metadata, as depicted in Figure 10. For example, if the initial >> classification returns the tenant information, a secondary >> classification (perhaps co-resident with DPI or SLB) may augment >> --- 1162,1170 ---- >> 7.2. Updating/Augmenting Metadata >> >> Post-initial metadata imposition (typically performed during initial >> ! service path determination) of metadata may be augmented or >>updated: >> >> ! 1. Metadata Augmentation: Information may be added to an NSH's >>existing >> metadata, as depicted in Figure 10. For example, if the initial >> classification returns the tenant information, a secondary >> classification (perhaps co-resident with DPI or SLB) may augment >> *************** >> *** 1184,1190 **** >> 2. Metadata Update: Subsequent classifiers may update the initial >> classification if it is determined to be incorrect or not >> descriptive enough. For example, the initial classifier adds >> ! metadata that describes the traffic as "internet" but a >>security >> service function determines that the traffic is really "attack". >> Figure 11 illustrates an example of updating metadata. >> >> --- 1185,1191 ---- >> 2. Metadata Update: Subsequent classifiers may update the initial >> classification if it is determined to be incorrect or not >> descriptive enough. For example, the initial classifier adds >> ! metadata that describes the traffic as "Internet" but a >>security >> service function determines that the traffic is really "attack". >> Figure 11 illustrates an example of updating metadata. >> >> *************** >> *** 1201,1207 **** >> +---+---+ employees employee+ >> | | Class=AppZ appZ >> +-------+ >> ! external >> system: >> Employee >> >> --- 1202,1208 ---- >> +---+---+ employees employee+ >> | | Class=AppZ appZ >> +-------+ >> ! External >> system: >> Employee >> >> *************** >> *** 1290,1296 **** >> Internet-Draft Network Service Header (NSH) July >>2017 >> >> >> ! NSH is always encapsulated in a transport protocol and therefore, >> when required, existing security protocols that provide authenticity >> (e.g., [RFC6071]) can be used. Similarly, if confidentiality is >> required, existing encryption protocols can be used in conjunction >> --- 1291,1297 ---- >> Internet-Draft Network Service Header (NSH) July >>2017 >> >> >> ! An NSH is always encapsulated in a transport protocol and >>therefore, >> when required, existing security protocols that provide authenticity >> (e.g., [RFC6071]) can be used. Similarly, if confidentiality is >> required, existing encryption protocols can be used in conjunction >> *************** >> *** 1303,1314 **** >> >> NSH metadata authenticity and confidentiality must be considered as >> well. In order to protect the metadata, an operator can leverage >>the >> ! aforementioned mechanisms provided the transport layer, >>authenticity >> and/or confidentiality. An operator MUST carefully select the >> ! transport/underlay services to ensure end to end security services, >> ! when those are sought after. For example, if [RFC6071] is used, >>the >> operator MUST ensure it can be supported by the transport/underlay >>of >> ! all relevant network segments as well as SFF and SFs. Further, as >> described in Section 8.1, operators can and should use indirect >> identification for personally identifying information, thus >> significantly mitigating the risk of privacy violation. Means to >> --- 1304,1316 ---- >> >> NSH metadata authenticity and confidentiality must be considered as >> well. In order to protect the metadata, an operator can leverage >>the >> ! aforementioned mechanisms provided by the transport layer >>including authenticity >> and/or confidentiality. An operator MUST carefully select the >> ! transport/underlay services to ensure end-to-end security services, >> ! when those are sought. For example, if [RFC6071] is used, the >> operator MUST ensure it can be supported by the transport/underlay >>of >> ! all relevant network segments as well as SFF and SFs in the >>service path. >> ! Further, as >> described in Section 8.1, operators can and should use indirect >> identification for personally identifying information, thus >> significantly mitigating the risk of privacy violation. Means to >> *************** >> *** 1318,1324 **** >> packet upstream. >> >> Lastly, SF security, although out of scope of this document, should >> ! be considered, particularly if an SF needs to access, authenticate >>or >> update NSH metadata. >> >> 9. Contributors >> --- 1320,1326 ---- >> packet upstream. >> >> Lastly, SF security, although out of scope of this document, should >> ! be considered, particularly if an SF needs to access, >>authenticate, or >> update NSH metadata. >> >> 9. Contributors >> *************** >> *** 1466,1472 **** >> design. >> >> The editors also acknowledge comprehensive reviews and respective >> ! suggestions by Med Boucadair and Adrian Farrel. >> >> Lastly, David Dolson has provides significant review, feedback and >> suggestions throughout the evolution of this document. His >> --- 1468,1474 ---- >> design. >> >> The editors also acknowledge comprehensive reviews and respective >> ! suggestions by Med Boucadair, Adrian Farrel, and Acee Lindem. >> >> Lastly, David Dolson has provides significant review, feedback and >> suggestions throughout the evolution of this document. His >> >> Thanks, >> Acee > >— >Carlos Pignataro, carlos@cisco.com > >“Sometimes I use big words that I do not fully understand, to make myself >sound more photosynthesis." >
- [sfc] Routing Directorate Last Call Review for dr… Acee Lindem (acee)
- Re: [sfc] Routing Directorate Last Call Review fo… Alia Atlas
- Re: [sfc] Routing Directorate Last Call Review fo… Carlos Pignataro (cpignata)
- Re: [sfc] [RTG-DIR] Routing Directorate Last Call… Joel M. Halpern
- Re: [sfc] Routing Directorate Last Call Review fo… Carlos Pignataro
- Re: [sfc] [RTG-DIR] Routing Directorate Last Call… Carlos Pignataro (cpignata)
- Re: [sfc] Routing Directorate Last Call Review fo… Acee Lindem (acee)
- Re: [sfc] Routing Directorate Last Call Review fo… Carlos Pignataro (cpignata)