Subject: Re: [nsc] Comments on draft-quinn-nsh-00

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 15 Jul 2013 23:08:31 +0000

Jim,

Yes, metadata is required. A special purpose label would be used to indicate the presence of metadata (as you indicated).  I am familiar with the method you suggested in the drafts (I actually read them all ;-).

I followed Thomas Narten suggestion (which is a good one) to "focus discussion on whether some item of information needs to be included in a packet or not, and the motivation/pros/cons of doing that". I was trying to point out some potential "cons" with the approach defined in the draft under discussion.

There are certainly solutions possible where NSH base header (and MCH) are not needed, and where is there is no global service chain identifier signaled in the data plane. They just need to be documented.

Maria

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 6:33 PM
To: NAPIERALA, MARIA H
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Maria,

As I indicated in a previous email it is certainly possible, and valid, to build simple service chains through construction of a forwarding path using import/export policy such as suggested in draft-rfernando-l3vpn-service-chaining-01, or an MPLS label stack where each label in the stack provides context to indicates which service function should be applied at which service hop.

However, the problem space is much broader than this as we have tried to outline in draft-quinn-nsc-problem-statement-02. If it is necessary (and I believe there are a growing number of use cases to support such an assumption) to construct service chains that will require the passing of metadata between service functions along the chain then relying on IP forwarding or an MPLS label stack is not sufficient; there needs to be additional intelligence that enables these existing forwarding mechanisms to carry said metadata.

I outlined a possible method for this in draft-guichard-mpls-metadata-00; the proposed solution in that draft is to utilize the existing GAL label (rather than obtaining a reserved label that may only serve a single purpose such as the passing of metadata relevant to service chaining) to indicate that metadata follows the label stack. As you will see in that draft, once you get past the label stack you have to define a common format that is able to carry the metadata (we call this a Metadata Channel Header (MCH) which would have a reserved type to signal the presence of NSH) and once you do that you have already gone above and beyond what existing standards provide whether it be IP or MPLS based.  The GAL label signals the presence of the NSH service header, where we can leverage the chain (pathing) _and_ the service context headers.

From: <NAPIERALA>, MARIA H <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 15, 2013 2:48 PM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: FW: [nsc] Comments on draft-quinn-nsh-00

Hi Jim,

Thanks for the reply. Please my responses in-line.

Maria

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Monday, July 15, 2013 12:09 PM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: [email-masked]<mailto:[email-masked]>; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Maria,

Thank you for your comments on our draft. Please see inline for responses.

From: <NAPIERALA>, MARIA H <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:[email-masked]>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing that.

I agree. I have three comments that fall in this category:

*        Is it necessary to have a new header that identifies a service (called Base Header in the draft)? Base Header implies new forwarding paradigm on the edge. In my opinion using MPLS labels to identify a service chain and a specific service will do the job.

Jim>  it is certainly a true statement that an MPLS label could be used (assuming that the network environment supports/deploys MPLS; a large assumption),

<MN> The draft introduces new encapsulation which would need to be supported at the network edge.
      At least, MPLS is not new ;-)

as could an IP tunnel, to get packets from point A to point B and at point B use said label value, or IP tunnel context, to indicate a given service function to be applied to the traffic. However, service chaining will require more than simply a forwarding mechanism between service functions: at a minimum service visibility and information exchange will be key.

<MN> I am not sure what is meant by "service visibility"?
     MPLS label can be also used to identify the service. Metadata would follow MPLS label stack.

*        Having a Global service chain identifier (called Service Path which is a part of Base Header) might not be a good idea. It will make service chaining less flexible. MPLS labels, on the other hand, have only local significance.

Jim> could you provide a more detailed description of why service chaining would be less flexible if a global service chain identifier is adopted?

<MN> A specific service may belong to multiple service chains. IMO, a service node should notbe aware of service chains it serves but only of whatservices it provides.
Since the draft makes the servicenodes aware of service chains, the service nodes need to carry mappings between service chains and the services they provide. This introduces additional complexity on the service nodes.
For example, if a particular service is removed from a service chain, the service_chain-to-service mapping has to be cleaned up on the removed service node.
Assume initially, two flow classifications (say, class1 and class2) are mapped to the same service chain (say, chain1). Subsequently, class2 traffic needs one additional service in front of chain1. According to the draft, new unique service chain has to be created (say, chain2) for class2 traffic. This creates a lot of duplicated state. Hence, what is needed is a locally significant chain identifier.
Since service chain identifiers have to be globally unique, maintaining them will not be trivial.

[X]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:[email-masked]>>
> To: Robert Raszuk <robert at raszuk.net<mailto:[email-masked]>>
> Cc: <nsc at ietf.org<mailto:[email-masked]>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 19 Jul 2013 22:20:00 +0000

Jim,

In that case, the chain identifier is not needed. This information is already present, i.e., it is implicit in the chain's forwarding path (e.g., MPLS VPN). Managing and carrying an explicit chain identifier is an unnecessary overhead.

Maria

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Friday, July 19, 2013 3:24 PM
To: NAPIERALA, MARIA H; Surendra Kumar (smkumar)
Cc: [email-masked]
Subject: Re: [nsc] FW: FW: Comments on draft-quinn-nsh-00

Maria,
The draft specifies that the participating node must use the base header for selecting the next service in the service path but its does not specify that the location of said next service must be carried in the header. There is therefore no co-mingling of network connectivity and signaling of metadata implied in the wording of the draft.

From: <NAPIERALA>, MARIA H <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 19, 2013 12:58 AM
To: "Surendra Kumar (smkumar)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [nsc] FW: FW: Comments on draft-quinn-nsh-00

Surendra,

Thanks for clarifying few aspects of the proposal. Please see in-line.

Maria

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Tuesday, July 16, 2013 3:38 PM
To: NAPIERALA, MARIA H; Jim Guichard (jguichar)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nsc] FW: Comments on draft-quinn-nsh-00

<MN> Cut off text.
[...]

<SK> In general I would tend to agree with notion that services should be focused on the service functions. A service has the service function and it may have a forwarding component or interact with one.
The forwarding component may be tasked to manipulate the service header. The network or the infrastructure may provide that for the service to integrate with (see below comment as well) strongly or as a proxy. The header does not dictate any of this. For those services that do own both the components, the draft does not prevent the use of the header.

<MN> Actually, the draft says that "Participating nodes *MUST* use the base header for selecting the next service in the service path".

Commingling signaling of network connectivity with signaling of metadata is unnecessary and counterproductive, IMO.