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

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

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.
-       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.
-       Having a fixed size Metadata might be too limiting. I believe we need to structure it such that it is extensible.

Maria
[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: Ron Parker <[email-masked]>
Date: Mon, 15 Jul 2013 15:33:10 +0000

Maria,

I agree that the pros/cons of a new IP-level encapsulation need to be discussed ahead of the actual content.    One important input to that discussion is whether MPLS is a requirement for Network Service Chaining, or if Network Service Chaining merely requires IP connectivity amongst the network functions.   Another input to the discussion is whether the chain describes (e.g., via MPLS label(s) and/or IP-level encapsulation) merely the identity of the sequence of network functions, or also suggests a per-network-function policy set to be applied (that is, additional value provided by the orchestrator).

   Ron Parker
   Affirmed Networks

From: [email-masked] [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H
Sent: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten'
Cc: [email-masked]; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

*         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.
*         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.
*         Having a fixed size Metadata might be too limiting. I believe we need to structure it such that it is extensible.

Maria
[X]

Thomas

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 15 Jul 2013 16:09:20 +0000

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

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), 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.

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

Maria
[X]

Thomas

---

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

Ron,

Please see in-line.

Maria

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, July 15, 2013 11:33 AM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: [email-masked]; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Maria,

I agree that the pros/cons of a new IP-level encapsulation need to be discussed ahead of the actual content.
One important input to that discussion is whether MPLS is a requirement for Network Service Chaining, or if Network Service Chaining merely requires IP connectivity amongst the
<MN> IP-only connectivity (if I understand you correctly) will require IP flow classification at every service hop .

network functions.   Another input to the discussion is whether the chain describes (e.g., via MPLS label(s) and/or IP-level encapsulation) merely the identity of the sequence of network functions, or also suggests a per-network-function policy set to be applied (that is, additional value provided by the orchestrator).

<MN> In my opinion, both.

   Ron Parker
   Affirmed Networks

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

Maria
[X]

Thomas

---

From: Ron Parker <[email-masked]>
Date: Mon, 15 Jul 2013 16:29:43 +0000

Thanks, Maria.

My followup, inline after yours.

   Ron

From: NAPIERALA, MARIA H [mailto:[email-masked]]
Sent: Monday, July 15, 2013 12:15 PM
To: Ron Parker; 'Thomas Narten'
Cc: [email-masked]; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Ron,

Please see in-line.

Maria

Maria,

I agree that the pros/cons of a new IP-level encapsulation need to be discussed ahead of the actual content.
One important input to that discussion is whether MPLS is a requirement for Network Service Chaining, or if Network Service Chaining merely requires IP connectivity amongst the
<MN> IP-only connectivity (if I understand you correctly) will require IP flow classification at every service hop .
<Ron> -- Without an encapsulation of some sort, then yes, each hop would need to independently determine the next hop.   But I don't think this is the approach envisioned by the NSC drafts, so far, including Quinn and Boucadair.   There are 2 approaches that can be considered.   In the first, a global chain ID could be conveyed on the wire.   Either via a control plane or via coordinated management plane actions, each hop would fully understand the semantics of the global chain ID.   In the second approach a stack of hops could be sent on the wire with an expectation that each hop pops its own entry.    Both approaches could be achieved with MPLS (single label or stack of labels).   The first could also be achieved through existing IP layer encapsulations (i.e., GRE, using its key as the chain ID), or new encapsulations.   The latter could also be achieved with a new encapsulation.
<Ron>

<Ron> Mine, also.

   Ron Parker
   Affirmed Networks

Maria
[Image removed by sender.]

Thomas

---

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

Ron,

Thanks. Please see in-line.

Maria

Sent: Monday, July 15, 2013 12:30 PM

Thanks, Maria.

   Ron

Ron,

Please see in-line.

Maria

Maria,

I agree that the pros/cons of a new IP-level encapsulation need to be discussed ahead of the actual content.
One important input to that discussion is whether MPLS is a requirement for Network Service Chaining, or if Network Service Chaining merely requires IP connectivity amongst the
<MN> IP-only connectivity (if I understand you correctly) will require IP flow classification at every service hop .
<Ron> -- Without an encapsulation of some sort, then yes, each hop would need to independently determine the next hop.   But I don't think this is the approach envisioned by the NSC drafts, so far, including Quinn and Boucadair.   There are 2 approaches that can be considered.   In the first, a global chain ID could be conveyed on the wire.   Either via a control plane or via coordinated management plane actions, each hop would fully understand the semantics of the global chain ID.

<mn> I have a different view. I don't think a global chain ID is a good idea. MPLS labels can locally identify service chains and services on service nodes. They have local significance and would be swapped at every service hop.

In the second approach a stack of hops could be sent on the wire with an expectation that each hop pops its own entry.
<mn> I must admit I have not read this draft.

Both approaches could be achieved with MPLS (single label or stack of labels).   The first could also be achieved through existing IP layer encapsulations (i.e., GRE, using its key as the chain ID), or new encapsulations.   The latter could also be achieved with a new encapsulation.
<Ron>

   Ron Parker
   Affirmed Networks

Maria

Thomas

---

From: Ron Parker <[email-masked]>
Date: Mon, 15 Jul 2013 19:55:05 +0000

Maria,

Conveyance of a stack of next-hops explicitly on the wire, via MPLS or a new IP-layer encapsulation, is not currently discussed in the NSC-related Internet-Drafts, to my knowledge.   I think it is a fruitful area for a new I-D, however, to facilitate consideration of the concept.

   Ron

Sent: Monday, July 15, 2013 3:43 PM

Ron,

Maria

Thanks, Maria.

   Ron

Ron,

Please see in-line.

Maria

Maria,

   Ron Parker
   Affirmed Networks

Maria

Thomas

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Jul 2013 22:15:27 +0200

Hi Ron,

Just out of curiosity are you familiar with
draft-patel-raszuk-bgp-vector-routing-00.txt

NSC is one of target's WG for this draft.

Cheers,
R.

On Mon, Jul 15, 2013 at 9:55 PM, Ron Parker
<[email-masked]> wrote:
> <Ron> -- Without an encapsulation of some sort, then yes, each hop would need to independently determine the next hop.   But I don’t think this is the approach envisioned by the NSC drafts, so far, including Quinn and Boucadair.   There are 2 approaches that can be considered.   In the first, a global chain ID could be conveyed on the wire.   Either via a control plane or via coordinated management plane actions, each hop would fully understand the semantics of the global chain ID.
>
>
>
> <mn> I have a different view. I don’t think a global chain ID is a good idea. MPLS labels can locally identify service chains and services on service nodes. They have local significance and would be swapped at every service hop.
>
>
>
> Thomas Narten <narten at us.ibm.com> writes:
>
>
>
> ·         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.
>
> ·         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.
>
> ·         Having a fixed size Metadata might be too limiting. I believe we need to structure it such that it is extensible.
>
>
>
> Maria
>
> > From: Thomas Narten <narten at us.ibm.com>
>
> > To: Robert Raszuk <robert at raszuk.net>
>
> > Cc: <nsc at ietf.org>
>

---

From: Ron Parker <[email-masked]>
Date: Mon, 15 Jul 2013 21:21:44 +0000

Thanks, Robert.

I hadn't seen that.   Interesting approach to a control plane that minimizes impact on the data plane.   It does, however, impose the BGP requirement, something that is often not true within the data center.

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, July 15, 2013 4:15 PM
To: Ron Parker
Cc: NAPIERALA, MARIA H; Thomas Narten; [email-masked]
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Ron,

Just out of curiosity are you familiar with draft-patel-raszuk-bgp-vector-routing-00.txt

Cheers,
R.

On Mon, Jul 15, 2013 at 9:55 PM, Ron Parker <[email-masked]> wrote:
> One important input to that discussion is whether MPLS is a 
> requirement for Network Service Chaining, or if Network Service 
> Chaining merely requires IP connectivity amongst the
>