Subject: [sfc] NSH and UDP Transport

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 20 Apr 2015 23:02:40 +0000

Hello Chairs,

The hallmark of NSH is that it can be transported over many different overlays. Towards that, we already have an ether-type that allows us to carry NSH natively over Ethernet and non-natively over UDP – via VXLAN-GPE. Given that UDP is the basic, simplest and most common overlay transports, we should enable transporting NSH natively over UDP, as well.

Is there a process for requesting a UDP port# for NSH for working group drafts ? Alternatively, in the spirit of saving the UDP name space, is it okay to transfer a pre-allocated but un-used UDP port# ? As part of my work, I had UDP port# 6633 allocated a couple of years ago for a similar purpose. This number is unused and I would be glad to transfer this over to NSH.

Thanks,
Surendra.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Apr 2015 19:38:37 -0400

This seems a reasonable course, but defining how the NSH header is 
carried on various transports seems not to be in my reading of the WG 
scope.

In particular, it seems a bit odd to define the mechanisms for some 
randomly selected subset of transports.  Thus, while the omission is 
arguably a bug in the charter, it is equally a bug to decide we will 
describe how to handle some transports.  And do we really want to have 
to produce documents for each and every transport?

Yours,
Joel

On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote:
> Hello Chairs,
>
> The hallmark of NSH is that it can be transported over many different
> overlays. Towards that, we already have an ether-type that allows us to
> carry NSH natively over Ethernet and non-natively over UDP – via
> VXLAN-GPE. Given that UDP is the basic, simplest and most common overlay
> transports, we should enable transporting NSH natively over UDP, as well.
>
> Is there a process for requesting a UDP port# for NSH for working group
> drafts ? Alternatively, in the spirit of saving the UDP name space, is
> it okay to transfer a pre-allocated but un-used UDP port# ? As part of
> my work, I had UDP port# 6633 allocated a couple of years ago for a
> similar purpose. This number is unused and I would be glad to transfer
> this over to NSH.
>
> Thanks,
> Surendra.
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 21 Apr 2015 01:29:33 +0000

Hi Surendra,

I fully agree with you that we should enable transporting NSH natively over UDP as well.

Best regards,
Xiaohu

From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar (smkumar)
Sent: Tuesday, April 21, 2015 7:03 AM
To: Jim Guichard (jguichar); Thomas Narten
Cc: [email-masked]
Subject: [sfc] NSH and UDP Transport

Hello Chairs,

The hallmark of NSH is that it can be transported over many different overlays. Towards that, we already have an ether-type that allows us to carry NSH natively over Ethernet and non-natively over UDP - via VXLAN-GPE. Given that UDP is the basic, simplest and most common overlay transports, we should enable transporting NSH natively over UDP, as well.

Thanks,
Surendra.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 21 Apr 2015 01:36:12 +0000

Hi Joel,

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, April 21, 2015 7:39 AM
> To: Surendra Kumar (smkumar); Jim Guichard (jguichar); Thomas Narten
> Cc: [email-masked]
> Subject: Re: [sfc] NSH and UDP Transport
> 
> This seems a reasonable course, but defining how the NSH header is carried on
> various transports seems not to be in my reading of the WG scope.
> 
> In particular, it seems a bit odd to define the mechanisms for some randomly
> selected subset of transports.  Thus, while the omission is arguably a bug in the
> charter, it is equally a bug to decide we will describe how to handle some
> transports.  And do we really want to have to produce documents for each and
> every transport?

IMHO, we should at least produce documents for some common transports, such as UDP/IP and MPLS.

Best regards,
Xiaohu

> > overlays. Towards that, we already have an ether-type that allows us
> > to carry NSH natively over Ethernet and non-natively over UDP - via
> > VXLAN-GPE. Given that UDP is the basic, simplest and most common
> > overlay transports, we should enable transporting NSH natively over UDP, as
> well.
> >
> > Is there a process for requesting a UDP port# for NSH for working
> > group drafts ? Alternatively, in the spirit of saving the UDP name
> > space, is it okay to transfer a pre-allocated but un-used UDP port# ?
> > As part of my work, I had UDP port# 6633 allocated a couple of years
> > ago for a similar purpose. This number is unused and I would be glad
> > to transfer this over to NSH.
> >
> > Thanks,
> > Surendra.
> >
> >

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 21 Apr 2015 06:05:35 +0000

I may be missing the point, without a transport NSH becomes meaningless,
whether charter calls for it or not. And when NSH is defined to be
transport independent, it is imperative we show it carried over the basic
ones.

Just a cursory look at the newly minted NVO3 encapsulations tells us how
many are not over UDP. UDP does not even impose additional functionality
requirements as is done by VxLAN like transports. If the goal is to enable
wide and easy adoption of NSH without barrier to entry, UDP seems like a
trivial one. So, UDP by any stretch is not a random choice in that sense.

Btw, this is just a means to enable carrying NSH, without altering any bit
or re-defining any of NSH. Absolutely not advocating yet another draft to
say ³NSH port# is x". Just allocating/recycling the port# and including it
in the NSH draft suffices - probably a one line change to NSH.

Surendra.

On 4/20/15, 4:38 PM, "Joel M. Halpern" <[email-masked]> wrote:

>> carry NSH natively over Ethernet and non-natively over UDP  via

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 21 Apr 2015 07:27:30 -0400

If and when we do go with an inline encap, which I think we should BTW, let us please not re-live the "challenges" we endured with pseudo-wires 
where we defined them piecemeal, and in some cases, quite differently from the others. PWs are a related archetype of what we would be doing here, so we should learn from that past experience.  For those not lucky enough to be part of that, the way we went about designing the encaps/etc... for PWs resulted in having to go back and try to make things right only to be thwarted by existing implementations and deployments a number of times. We also had to retrofit OAM into that after the train left the station which was not easy and is still being normalized many years later.

	--Tom

> On Apr 20, 2015:7:38 PM, at 7:38 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> This seems a reasonable course, but defining how the NSH header is carried on various transports seems not to be in my reading of the WG scope.
> 
> In particular, it seems a bit odd to define the mechanisms for some randomly selected subset of transports.  Thus, while the omission is arguably a bug in the charter, it is equally a bug to decide we will describe how to handle some transports.  And do we really want to have to produce documents for each and every transport?
> 
> Yours,
> Joel
>

---

From: Dave Dolson <[email-masked]>
Date: Tue, 21 Apr 2015 15:06:41 +0000

To my mind, Tom's statements indicate an urgency to standardize sooner rather than later.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Tuesday, April 21, 2015 7:28 AM
To: Joel M. Halpern
Cc: Thomas Narten; Guichard Jim; Surendra Kumar (smkumar); [email-masked]
Subject: Re: [sfc] NSH and UDP Transport

	--Tom

>> carry NSH natively over Ethernet and non-natively over UDP - via

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 22 Apr 2015 05:00:22 +0000

There is already an inline encapsulation in NSH draft -
Layer2(ether-type). We need one for L4.

If I¹m an operator deploying an NFV solution on an L3 infrastructure, as
one example, why do I need the overhead of VxLAN* ? It is broken out the
door if we force a specific transport that is on top of UDP while not
supporting UDP itself.

Surendra.
PS: As for the urgency, UDP #6633 is available if WG/IETF has no
objection, as I mentioned earlier.

On 4/21/15, 8:06 AM, "Dave Dolson" <[email-masked]> wrote:

>	If and when we do go with an inline encap, which I think we should BTW,
>let us please not re-live the "challenges" we endured with pseudo-wires
>where we defined them piecemeal, and in some cases, quite differently
>from the others. PWs are a related archetype of what we would be doing
>here, so we should learn from that past experience.  For those not lucky
>enough to be part of that, the way we went about designing the
>encaps/etc... for PWs resulted in having to go back and try to make
>things right only to be thwarted by existing implementations and
>deployments a number of times. We also had to retrofit OAM into that
>after the train left the station which was not easy and is still being
>normalized many years later.
>
>	--Tom
>
>
>
>>>overlay

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 22 Apr 2015 06:38:14 +0000

What is the packet format of such encapsulation would look like?

L2 ::  OUTER-IP :: OUTER-UDP [ NSH -> IP ->TCP -> Payload]  ... is that what you are proposing? 

I am not saving much on processing of this format, so what is the end goal?

________________________________________
From: sfc <[email-masked]> on behalf of Surendra Kumar (smkumar) <[email-masked]>
Sent: Tuesday, April 21, 2015 10:00 PM
To: Dave Dolson; Thomas D. Nadeau; Joel M. Halpern
Cc: Thomas Narten; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] NSH and UDP Transport

Surendra.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 22 Apr 2015 12:33:14 +0000

Joel, 

I concur: we don't want to start picking transports here, it creates all kinds of issues and is clearly out of scope.  

Rather, if there's a need for a transport to support NSH, then the work can occur in the associated working group.  So, if there's a need for MPLS, then a draft can be submitted to MPLS, similarly, NVO3, LISP, etc. can all have NSH supporting drafts.  This ensures both consistency and proper layering within the scope of those protocols.

On the UDP front specifically, there's a clear move to a explicit protocol demux:VXLAN-gpe, GUE, GENEVE etc.  That's probably the best place way to have a proper protocol stack.  

Paul

> On Apr 20, 2015, at 7:38 PM, Joel M. Halpern <[email-masked]> wrote:
>

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Thu, 23 Apr 2015 02:34:44 +0000

I agree. If we start specifying every single transport we will spent time that otherwise can be spent on SFC-focused work. 

There is no problem for other groups to specify how they want to encode SfC in their transport type and bring this to SFC for review. 

Andrew

> On Apr 22, 2015, at 5:33 AM, Paul Quinn (paulq) <[email-masked]> wrote:
> 
> Joel, 
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 23 Apr 2015 05:00:59 +0000

Sumandra,

There is overhead as you point out. NSH already provides MD-Type2 to reduce the NSH overhead, the argument has already been made and accepted.

It is fine to support SFC over VxLAN. However, why make that a requirement to deploy SFC ?
Why are we requiring provisioning of VNIs to deploy SFC ?
Why are we requiring VTEP functionality, etc to deploy SFC ?
Why are we adding more cost to deploy SFC ?
Why are we making it complex to deploy SFC in a simple L3 network ?

As for the stacking/layering:
                                             +------------+
                                             | NSH        |
                              +------------+ +------------+
                              | NSH        | | VxLAN*     |
               +------------+ +------------+ +------------+
               | NSH        | | L4-overlay | | L4-overlay |
+------------+ +------------+ +------------+ +------------+
| NSH        | | L3-overlay | | L3         | | L3         |
+------------+ +------------+ +------------+ +------------+
| L2-overlay | | L2         | | L2         | | L2         |
+------------+ +------------+ +------------+ +------------+
  L2/Etype        GRE/Etype      UDP/port#     VxLAN/proto

What is not proper about UDP/port# stacking/layering ?

Surendra.

On 4/21/15, 11:38 PM, "Sumandra Majee" <[email-masked]<mailto:[email-masked]>> wrote:

________________________________________
From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Surendra Kumar (smkumar) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, April 21, 2015 10:00 PM
To: Dave Dolson; Thomas D. Nadeau; Joel M. Halpern
Cc: Thomas Narten; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH and UDP Transport

Surendra.

On 4/21/15, 8:06 AM, "Dave Dolson" <[email-masked]<mailto:[email-masked]>> wrote:

To my mind, Tom's statements indicate an urgency to standardize sooner
rather than later.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Tuesday, April 21, 2015 7:28 AM
To: Joel M. Halpern
Cc: Thomas Narten; Guichard Jim; Surendra Kumar (smkumar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH and UDP Transport

       --Tom

On Apr 20, 2015:7:38 PM, at 7:38 PM, Joel M. Halpern
<[email-masked]<mailto:[email-masked]>> wrote:

Yours,
Joel

transports, we should enable transporting NSH natively over UDP, as
well.

Thanks,
Surendra.

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 23 Apr 2015 05:13:35 +0000

On 4/22/15, 5:33 AM, "Paul Quinn (paulq)" <[email-masked]> wrote:

>Joel, 
>
>I concur: we don't want to start picking transports here, it creates all
>kinds of issues and is clearly out of scope.
>
>Rather, if there's a need for a transport to support NSH, then the work
>can occur in the associated working group.  So, if there's a need for
>MPLS, then a draft can be submitted to MPLS, similarly, NVO3, LISP, etc.
>can all have NSH supporting drafts.  This ensures both consistency and
>proper layering within the scope of those protocols.
>
>On the UDP front specifically, there's a clear move to a explicit
>protocol demux:VXLAN-gpe, GUE, GENEVE etc.  That's probably the best
>place way to have a proper protocol stack.
NSH provides demux too. So, GUE and GENEVE are equivalent to NSH signaled
with UDP. I¹m not sure how using UDP port# makes the stack improper.

Surendra.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 23 Apr 2015 07:09:51 -0400

In PWE3 we eventually did specify each one, we just did it a little here and a little there. We had a different PW header and transport encap depending on the transport for quite a while, which proved to be rather interesting if you were implementing any of it. Worse if you were an operator trying to deploy multiple types. Eventually (think years later) we settled on a common header format, but there were already some pretty good sized deployments out there which resisted unifying the header.  The lesson: try to do it right from the beginning thinking that there will be multiple transport types.  So while SFC might not define the transport encaps, we should define a common header format that works with at least a few representative/obvious ones to start, and have a plan to define others in collaboration with SFC using the same mechanism.  Also consider OAM now, not halfway down the road.  That doesn’t mean we need to re-define existing mechanisms, but just make sure that if existing ones exist (which I think they do BTW), that they are incorporated into the unified plan somewhere.

	—Tom

> On Apr 22, 2015:10:34 PM, at 10:34 PM, Dolganow, Andrew (Andrew) <[email-masked]> wrote:
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 23 Apr 2015 12:55:47 +0000

I agree Tom that there are certainly lessons from the PWE3 work.

In that case, however, the actual “PWE3 header” (i.e., the Control Word) was specified piecemeal, for each protocol transported *over* the PW. For SFC, in contrast, the “SFC Header” is common and defined in a single place, the NSH, for whatever is transported *over* the NSH. I think this SFC WG decision is wise and might even show we have learned from the PWE3 experience.

Thanks,

— Carlos.

> On Apr 23, 2015, at 7:09 AM, Thomas D. Nadeau <[email-masked]> wrote:
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Apr 2015 09:47:34 -0400

I think I am missing your point Thomas.  We have an agreed common header 
(or at least an agreed basis and expectation that we will complete the 
rest expeditiously.)  So I do not see any risk of ending up with a 
different NSH header for each transport.

The question is where / when do we specify the transport details.

If Surendra wants to take the existing, registered, code point, and 
indicate that what it is to carry is NSH (and presumably update it again 
when the RFC comes out) that is fine.  I have no objection personally, 
and I can see no grounds for the working group to object.

Where I have some concern is with the description of the Ethernet code 
point and the UDP port in the NSH document.  That seems to be outside of 
the agreed scope.

Yours,
Joel

On 4/23/15 7:09 AM, Thomas D. Nadeau wrote:
>
> 	In PWE3 we eventually did specify each one, we just did it a little here and a little there. We had a different PW header and transport encap depending on the transport for quite a while, which proved to be rather interesting if you were implementing any of it. Worse if you were an operator trying to deploy multiple types. Eventually (think years later) we settled on a common header format, but there were already some pretty good sized deployments out there which resisted unifying the header.  The lesson: try to do it right from the beginning thinking that there will be multiple transport types.  So while SFC might not define the transport encaps, we should define a common header format that works with at least a few representative/obvious ones to start, and have a plan to define others in collaboration with SFC using the same mechanism.  Also consider OAM now, not halfway down the road.  That doesn’t mean we need to re-define existing mechanisms, but just make sure that if existi
 n
g ones exist (which I think they do BTW), that they are incorporated into the unified plan somewhere.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Apr 2015 09:50:21 -0400

Your questions below are precisely why the charter calls for us to be
transport independent.  We are not here to debate the benefits and
drawbacks of various transport.  No one other than you has asked to
mandate or require anything about the transports.

Yours,
Joel

> Sumandra,
...
> Why are we making it complex to deploy SFC in a simple L3 network ?
...

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 23 Apr 2015 09:57:20 -0400

> On Apr 23, 2015:9:47 AM, at 9:47 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> I think I am missing your point Thomas.  We have an agreed common header (or at least an agreed basis and expectation that we will complete the rest expeditiously.)  So I do not see any risk of ending up with a different NSH header for each transport.
> 

	Exactly. We need a common mapping/approach to transport - or at least some coordination here. It shouldn’t be done willy nilly.

	—Tom

> If Surendra wants to take the existing, registered, code point, and indicate that what it is to carry is NSH (and presumably update it again when the RFC comes out) that is fine.  I have no objection personally, and I can see no grounds for the working group to object.
> 
> Where I have some concern is with the description of the Ethernet code point and the UDP port in the NSH document.  That seems to be outside of the agreed scope.
> 
> Yours,
> Joel
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 23 Apr 2015 14:22:19 +0000

Hi Joel,

>The question is where / when do we specify the transport details.

Jim> our charter does not call for us to work on the transport details;
those should be addressed by the relevant WG for a given transport
pointing to our SFC encapsulation work.

>and I can see no grounds for the working group to object.

Jim> from a chairs perspective I also have no objection. Likewise if other
WG¹s want to define in their transports how NSH is indicated then that is
the right approach and I encourage it.

>> 	In PWE3 we eventually did specify each one, we just did it a little
>>here and a little there. We had a different PW header and transport
>>encap depending on the transport for quite a while, which proved to be
>>rather interesting if you were implementing any of it. Worse if you were
>>an operator trying to deploy multiple types. Eventually (think years
>>later) we settled on a common header format, but there were already some
>>pretty good sized deployments out there which resisted unifying the
>>header.  The lesson: try to do it right from the beginning thinking that
>>there will be multiple transport types.  So while SFC might not define
>>the transport encaps, we should define a common header format that works
>>with at least a few representative/obvious ones to start, and have a
>>plan to define others in collaboration with SFC using the same
>>mechanism.  Also consider OAM now, not halfway down the road.  That
>>doesn¹t mean we need to re-define existing mechanisms, but just make
>>sure that if existi
> n
>> 	‹Tom
>>> On Apr 22, 2015:10:34 PM, at 10:34 PM, Dolganow, Andrew (Andrew)
>>><[email-masked]> wrote:
>>>
>>> I agree. If we start specifying every single transport we will spent
>>>time that otherwise can be spent on SFC-focused work.
>>>
>>> There is no problem for other groups to specify how they want to
>>>encode SfC in their transport type and bring this to SFC for review.
>>>
>>> Andrew
>>>
>>>
>>>> I concur: we don't want to start picking transports here, it creates
>>>>all kinds of issues and is clearly out of scope.
>>>>
>>>> Rather, if there's a need for a transport to support NSH, then the
>>>>work can occur in the associated working group.  So, if there's a need
>>>>for MPLS, then a draft can be submitted to MPLS, similarly, NVO3,
>>>>LISP, etc. can all have NSH supporting drafts.  This ensures both
>>>>consistency and proper layering within the scope of those protocols.
>>>>
>>>>>describe how to handle some transports.  And do we really want to
>>>>>have to produce documents for each and every transport?
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>>>group

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Thu, 23 Apr 2015 15:11:09 +0000

inline

>pointing to our SFC encapsulation work.
Agree, maybe we should more explict in the SFC draft and say that NSH
header must remain transport agnostic, so someone in the future does not
try to put transport specifics in the NSH header.
>the right approach and I encourage it.
Agree

>>point and the UDP port in the NSH document.  That seems to be outside of

We did needed at least some first application encoding just so we have at
least a sample of transport. Maybe we should put some explanatory note
towards that in the SFC draft?

Andrew

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 23 Apr 2015 15:47:50 +0000

Joel,

--
--

Based on this, we should remove section 11 altogether from the NSH draft.
Then, that brings up the question of, why we are we even standardizing
something we don¹t know how to signal. It seems like an effort in the void.

Surendra.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 23 Apr 2015 16:07:36 +0000

Joel,

I¹ve always been saying that the strong point of NSH is that it is
transport independent, unlike GENEVE (in nvo3 archives), for instance.
Which in fact provides equivalent header capabilities, but has a specific
transport .

I agree we can¹t enumerate all transports and go modify them all from SFC
WG. As I showed in the the other diagram, we should demonstrate this
transport independence in the fundamental layers of the IP stack. We have
ether type that covers L2 and L3. We should have one for L4.

To me, native ethernet and native UDP are foundational. The rest can be
done in other working groups as you suggest. We have the demux in NSH just
as GUE and GENEVE to signal payloads.

Btw, I am no way tied to 6633. WG can allocate another one and that would
be fine.
Surendra.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Apr 2015 12:13:03 -0400

One of the reasons why I appreciated the way the charter was drawn is 
that arguing about which transports are "foundational" does not actually 
help anyone.  I understand why you consider those "foundational"  Given 
that it is out of scope for the group, and provides no benefit to the 
group, I would prefer not to get into a series of debates about which 
ones are actually foundational.

As a corollary, I see no reason to use a different UDP port than the one 
you have.  I just don't see it as the WG job to pick.

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 23 Apr 2015 16:32:14 +0000

If the WG agrees with this, then there is no place for section 11 in NSH
draft and we should remove it!
Why document a specific set of transports ?

Surendra.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 23 Apr 2015 16:35:39 +0000

>pointing to our SFC encapsulation work.
SK> Let’s remove section 11

>the right approach and I encourage it.
SK> same as above

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Apr 2015 12:35:16 -0400

That would be fine with me.
Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 23 Apr 2015 16:45:05 +0000

Agree. 

  Ron

> On Apr 23, 2015, at 6:36 PM, Joel M. Halpern <[email-masked]> wrote:
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 23 Apr 2015 16:52:14 +0000

“There is no place” is incorrect. Section 11 is titled “NSH Encapsulation Examples”.

— Carlos.

> On Apr 23, 2015, at 12:32 PM, Surendra Kumar (smkumar) <[email-masked]> wrote:
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 23 Apr 2015 17:10:18 +0000

That is a convenience argument. That is a bias in itself.
Then I would argue, request a UDP port# from IANA and document it in NSH
and show an example of it.

There is probably a reason all of the below use ONLY UDP!
GENEV    : UDP# 6081
GUE      : UDP# 6080
VxLAN    : UDP# 4790
VxLAN-gpe: UDP# 4789

And yet, we are in denial.

Surendra.

On 4/23/15, 9:52 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

>― Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 23 Apr 2015 17:33:42 +0000

Surendra,

The only argument I made is that your characterization was incorrect (and, since you mention it, also biased). It is not for convenience, simply for correctness. You said “there is no place”, while actually there is place, that the WG can decide how to fill (from “NSH is transport agnostic, all details specified elsewhere” to something more explicit, including or not the encap you have in mind, or “NSH over Avian Carriers").

Now, who is “we” in “we are in denial”? And is that because of your attempt at cataloging “foundational” transports? Or your comparison of NSH with VxLAN as an attempt of an argument? I do not follow either...

The pragmatic in me says that the approach of MPLS in RFC 3032 of documenting a couple deployed common ones was useful; too comprehensive, not too useful.

Thanks,

— Carlos.

> On Apr 23, 2015, at 1:10 PM, Surendra Kumar (smkumar) <[email-masked]> wrote:
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 24 Apr 2015 02:01:01 +0000

+1

Best regards,
Xiaohu

> Sent: Friday, April 24, 2015 12:35 AM
> Cc: [email-masked]
> > If the WG agrees with this, then there is no place for section 11 in
> > NSH draft and we should remove it!
> >> that arguing about which transports are "foundational" does not
> >> actually help anyone.  I understand why you consider those
> >> "foundational"  Given that it is out of scope for the group, and
> >> provides no benefit to the group, I would prefer not to get into a
> >> series of debates about which ones are actually foundational.
> >>
> >> As a corollary, I see no reason to use a different UDP port than the
> >> one you have.  I just don't see it as the WG job to pick.
> >>
> >> Yours,
> >> Joel
> >>
> >>> Which in fact provides equivalent header capabilities, but has a
> >>> specific transport .
> >>>
> >>> I agree we can¹t enumerate all transports and go modify them all
> >>> from SFC WG. As I showed in the the other diagram, we should
> >>> demonstrate this transport independence in the fundamental layers of
> >>> the IP stack. We have ether type that covers L2 and L3. We should
> >>> have one for L4.
> >>>
> >>> To me, native ethernet and native UDP are foundational. The rest can
> >>> be done in other working groups as you suggest. We have the demux in
> >>> NSH just as GUE and GENEVE to signal payloads.
> >>>
> >>> Btw, I am no way tied to 6633. WG can allocate another one and that
> >>> would be fine.
> >>> Surendra.
> >>>
> >>>> Your questions below are precisely why the charter calls for us to
> >>>> be transport independent.  We are not here to debate the benefits
> >>>> and drawbacks of various transport.  No one other than you has
> >>>> asked to mandate or require anything about the transports.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 24 Apr 2015 02:57:58 +0000

Carlos,

There is a correctness and inconsistency problem given all the discussion
so far. Firstly, many on this thread, including the chair, think that
transport stuff should be taken outside the SFC WG into transport WGs.

However,
1. EtherType=0x894F is documented, without a transport WG draft, in
section 11 while at the same time UDP is not being allowed - the
inconsistency part
2. Since all signaling belongs in transport, protocol-field (demux) in NSH
seems to be out of scope - correctness issue.

We need to make amends to take care of these. I personally believe this is
too rigid and we should relax either the charter itself or the enforcement
of it to allow the protocol-field, ether-type and UDP, if not others.

Surendra.

On 4/23/15, 10:33 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

>Surendra,
>
>The only argument I made is that your characterization was incorrect
>(and, since you mention it, also biased). It is not for convenience,
>simply for correctness. You said “there is no place”, while actually
>there is place, that the WG can decide how to fill (from “NSH is
>transport agnostic, all details specified elsewhere” to something more
>explicit, including or not the encap you have in mind, or “NSH over Avian
>Carriers").
>
>Now, who is “we” in “we are in denial”? And is that because of your
>attempt at cataloging “foundational” transports? Or your comparison of
>NSH with VxLAN as an attempt of an argument? I do not follow either...
>
>The pragmatic in me says that the approach of MPLS in RFC 3032 of
>documenting a couple deployed common ones was useful; too comprehensive,
>not too useful.
>
>Thanks,
>
>― Carlos.
>
>>> “There is no place” is incorrect. Section 11 is titled “NSH
>>>Encapsulation
>>> Examples”.
>>> 
>>> ― Carlos.
>>> 
>>>>> actually
>>>>> one
>>>>>> specific
>>>>>>from
>>>>>> SFC
>>>>>> be
>>>>>> done in other working groups as you suggest. We have the demux in
>>>>>>NSH
>>>>>> just
>>>>>> would
>>>>>>>be

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Tue, 28 Apr 2015 01:46:07 +0000

Hi Jim,

If someone wanted to write a draft specifying how to carry NSH over UDP,
what WG would it be submitted to?  I usually see the protocols running
over UDP specify their UDP port number, not the other way around (UDP
doesn't specify what runs on top of it).  For example, VXLAN specifies
the UDP port used to carry it.  UDP does not specify what port to use to
carry VXLAN.  Is there an RFC you can point to as an example that simply
specifies a UDP port for another protocol to be carried?

Thanks, Larry

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 28 Apr 2015 02:03:58 +0000

Larry,

If you don't find a better home for it before Prague, potentially you could present in rtgwg, we will dispatch it afterwards.

Regards,
Jeff

> On Apr 27, 2015, at 9:46 PM, Larry Kreeger (kreeger) <[email-masked]> wrote:
> 
> Hi Jim,
>

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 28 Apr 2015 08:14:21 +0100

Hi, Larry and Jim -

Larry Kreeger (kreeger) wrote:
> If someone wanted to write a draft specifying how to carry NSH over 
> UDP, what WG would it be submitted to?

As you probably know, NVO3 WG has adopted VXLAN-GPE which is an example
of a NSH-capable transport. I think this is a good example of what Jim
described as a "relevant WG for a given transport".

But in the case of NSH carried directly in UDP, it seems to me that (as
Larry described) this is normally described in the protocol document
itself. Since NSH is intentionally flexible with regards to underlying
transport, I can imagine this being a companion document rather than
embedded in the NSH text. But in either case I think it makes the most
sense for the SFC WG to be the home for such a definition.

Cheers,
-Benson

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 28 Apr 2015 17:47:26 +0000

Thanks Benson, Larry!

I will produce a draft for both the UDP port# and the ether-type and
publish it within SFC WG based on the comments so far.
The chairs can move it to the appropriate WG if they think otherwise.

Surendra.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 28 Apr 2015 18:05:51 +0000

Hi Benson,

I think a separate companion document is probably the right way forward in
this case. RFC 7510 (MPLS in UDP) is perhaps a good example of how this
has been dealt with before. The key here is that the SFC encapsulation
remain transport independent and having a companion document for UDP and
other encapsulations in their respective WG¹s (such as VXLAN-GPE in NVO3
as you pointed out) satisfies this requirement.

Jim

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 28 Apr 2015 19:27:16 +0000

I that spirit, we should not include examples of encapsulation in NSH and
let these companion drafts do that.
Specifically, as discussed last week, section 11 conflicts with this
requirement.

Surendra.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 28 Apr 2015 20:43:20 +0000

Benson,

We should keep the strict separation of NSH and the transports.  So, in the case of VXLAN-GPE, we submitted it to NVO3 since GPE falls under the charter of that group.  If there's a need for a UDP only draft, it belongs either under transport, or as an individual submission, not SFC.

To keep things consistent, I'm happy to remove the ethertype allocation from draft-nsh, and simply leave that allocation with IEEE.

I am surprised that having some examples in the draft is causing consternation.  In my experience having those examples helped explain the stack, was something that folks asked about frequently and does not in any way promote or advocate for a given transport.  If the WG wants to give up that clarity then the draft can be updated accordingly.

Thanks
Paul

> On Apr 28, 2015, at 3:14 AM, Benson Schliesser <[email-masked]> wrote:
> 
> Hi, Larry and Jim -
>

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Tue, 28 Apr 2015 20:57:05 +0000

How about we mark the text as informational in the nsh draft, once drafts
for transports are accpeted, we can refer to those as examples?

Andrew

On 2015-04-28, 4:43 PM, "Paul Quinn (paulq)" wrote:

>Benson,
>
>We should keep the strict separation of NSH and the transports.  So, in
>the case of VXLAN-GPE, we submitted it to NVO3 since GPE falls under the
>charter of that group.  If there's a need for a UDP only draft, it
>belongs either under transport, or as an individual submission, not SFC.
>
>To keep things consistent, I'm happy to remove the ethertype allocation
>from draft-nsh, and simply leave that allocation with IEEE.
>
>I am surprised that having some examples in the draft is causing
>consternation.  In my experience having those examples helped explain the
>stack, was something that folks asked about frequently and does not in
>any way promote or advocate for a given transport.  If the WG wants to
>give up that clarity then the draft can be updated accordingly.
>
>Thanks
>Paul
>
>

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 28 Apr 2015 22:03:09 +0100

Hi, Paul.

Paul Quinn (paulq) wrote:
> We should keep the strict separation of NSH and the transports.  So,
> in the case of VXLAN-GPE, we submitted it to NVO3 since GPE falls
> under the charter of that group.  If there's a need for a UDP only
> draft, it belongs either under transport, or as an individual
> submission, not SFC.

For whatever it's worth, I don't really have a strong opinion about 
this. My earlier comments were simply noting how it is sometimes done. 
As far as I'm concerned, any choice (of document and/or WG) is good as 
long as it gets the appropriate review and can be cleanly referenced. 
And I trust the SFC chairs and NSH authors to figure this out.

Cheers,
-Benson

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Tue, 28 Apr 2015 22:03:43 +0000

Hi Jim,

Wasn't RFC7510 adopted by the MPLS WG?  If so, this was the WG responsible
for the protocol (MPLS) running over UDP. Do you have an example where the
protocol running over UDP was adopted by a WG not responsible for the
protocol running over UDP?

Thanks, Larry

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Tue, 28 Apr 2015 22:37:09 +0000

Thanks Jeff!  We will do that if a better home is not found before Prague.
 Paul Quinn suggested Transport (TSV WG).  Is there a precedent for these
types of drafts going to TSV WG?

 - Larry

On 4/27/15 7:03 PM, "Jeff Tantsura" <[email-masked]> wrote:

>Larry,
>
>If you don't find a better home for it before Prague, potentially you
>could present in rtgwg, we will dispatch it afterwards.
>
>Regards,
>Jeff
>