Re: [sfc] NSH and UDP Transport

["Surendra Kumar (smkumar)" <[e-mail]>]

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)" <[e-mail]>
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.
>
>> On Apr 23, 2015, at 1:10 PM, Surendra Kumar (smkumar)
>><[e-mail]> wrote:
>> 
>> 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)" <[e-mail]>
>> wrote:
>> 
>>> “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)
>>>> <[e-mail]> wrote:
>>>> 
>>>> 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.
>>>> 
>>>> On 4/23/15, 9:13 AM, "Joel M. Halpern" <[e-mail]> wrote:
>>>> 
>>>>> 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
>>>>> 
>>>>> On 4/23/15 12:07 PM, Surendra Kumar (smkumar) wrote:
>>>>>> 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.
>>>>>> 
>>>>>> On 4/23/15, 6:50 AM, "Joel M. Halpern" <[e-mail]> wrote:
>>>>>> 
>>>>>>> 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
>>>>>>> 
>>>>>>> On 4/23/15 1:00 AM, Surendra Kumar (smkumar) wrote:
>>>>>>>> Sumandra,
>>>>>>> ...
>>>>>>>> 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
>>>>>>>>?
>>>>>>> ...
>>>>>> 
>>>>>> 
>>>> 
>>>> _______________________________________________
>>>> sfc mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>> 
>> 
>