Re: [sfc] AD review of draft-ietf-sfc-nsh-18

On Fri, Aug 11, 2017 at 9:19 PM, Carlos Pignataro (cpignata) <
cpignata@cisco.com> wrote:

>
> On Aug 11, 2017, at 9:12 PM, Alia Atlas <akatlas@gmail.com> wrote:
>
>
>
> On Fri, Aug 11, 2017 at 9:09 PM, Carlos Pignataro (cpignata) <
> cpignata@cisco.com> wrote:
>
>> Thanks, Alia. Please see inline.
>>
>> On Aug 11, 2017, at 6:58 PM, Alia Atlas <akatlas@gmail.com> wrote:
>>
>> As is customary, I have done my AD review of draft-ietf-sfc-nsh-18.
>> First, I would like to thank the editors, Carlos, Uri, and Paul, as well as
>> the many contributors for their work on this document.  It has improved
>> substantially.
>>
>> I do have a few minor comments from my review.  They are below.  I will
>> proceed to ask for an IETF Last Call now and schedule this draft for Aug
>> 31; for that telechat date, I will require a very active shepherd as well
>> as editors.
>>
>> Please do SUBMIT the latest editor's version of this draft ASAP.  Version
>> numbers are cheap and it is much better for reviewers to see the latest
>> version. This must be the process going forward to avoid the same points
>> being brought up multiple times.
>>
>>
>> Sounds good.
>>
>>
>> 1) As Acee already noted, receivers of unassigned flags MUST ignore the
>> value.  There are a couple places to fix this.
>>
>>
>> Agreed. Done.
>>
>> 2) Given the consensus in NVO3 and that VXLAN-GPE will be progressed as
>> an informational document described an alternative that was not selected
>> for standardization, I would prefer a different example in Sec 6.1 Table 1.
>>
>>
>> This is just an example, non normative, non-binging, and list VXLAN-GPE
>> along with GRE and Ethernet. What would you prefer the document uses?
>>
>
> Geneve?  MPLS? UDP?
>
> Something Standards Track please.
>
>
> I think that would give the wrong impression that SFC can run only atop
> Standards Track IETF technology.
>
> The document currently lists: GRE, Standards Track. UDP in Table 3,
> Standards Track. VXLAN-GPE, Informational. And Ethernet. Sounds like a
> diverse mix.
>

VXLAN-GPE will be Informational - in the sense of an alternative considered
and not taken.

There is no reason to fail to respect the consensus in NVO3.  If you want
to toss in VXLAN, that'd be fine.

> If you insist, I could add more rows to the table to also be more
> inclusive in addition to diverse? I can also add more IPv6 NHs if so?
>
> Thanks!
>
> Carlos.
>
> Thanks,
> Alia
>
>
>> 3) In Sec 7.1, there is a sentence "In some cases they may terminate, and
>> be able to inspect encrypted traffic."  Unless there is a strong technical
>> need to point this out, I would pick a different example.  There is a great
>> deal of current controversy and discussion happening in TLS currently - and
>> this is likely to trigger that discussion unnecessarily.
>>
>>
>> Ack. Gone.
>>
>>
>> 4) I am happy to see that IEEE (https://regauth.standards.iee
>> e.org/standards-ra-web/pub/view.html#registries) is now showing the
>> EtherType 0x894F as referring to this draft.  Thanks!
>>
>>
>> Anytime :-)
>>
>> Thanks!
>>
>> Carlos.
>>
>>
>> Regards,
>> Alia
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>>
>> —
>> Carlos Pignataro, carlos@cisco.com
>>
>> *“Sometimes I use big words that I do not fully understand, to make
>> myself sound more photosynthesis."*
>>
>
> —
> Carlos Pignataro, carlos@cisco.com
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>