Re: [Rtg-dt-encap-considerations] Added Hardware Friendly to Dallas slides

["Larry Kreeger (kreeger)" <[e-mail]>]

On 3/11/15 4:18 PM, "Erik Nordmark" <[e-mail]> wrote:

>On 3/11/15 3:47 PM, Larry Kreeger (kreeger) wrote:
>> Hi Erik,
>>
>> Here are my comments on the slides.  I don't know if the hardware
>>friendly
>> slide will stimulate more discussion than several other points in these
>> slides, so I don't see why not to have it.
>OK, I've added the slide to the NVO3 set for now.
>>
>> Slide 7: I'm not sure what the bullet "Perhaps optional OAM info
>>modified
>> along path?" means.
>This was a vague reference to timestamps etc for OAM purposes. I've
>reworded it to be more specific.
>> Also, SFC allows not only the service path info to be
>> carried (and modified), but the service metadata may also be modified.
>Is " *Service meta-data may be modified by service functions" a correct
>state*ment?**

Yes.

>>
>> Slide 9: It isn't clear to me whether limiting the source port entropy
>>to
>> only use the ephemeral port range is required.  I think in many cases it
>> will be fine to use all 16 bits of source port.
>The document doesn't even specify exactly why, but has some more text.
>If there is some middlebox, it might look at the UDP source port. For
>instance, UDP source ports used by known insecure protocols might be
>blocked by a firewall. If all 16 bits are used that means some flows
>would get blocked. But in other deployments all bits can be used.

Yes, exactly.

>
>How about I have the slide say ">=14 bits" and we can talk to this point?

Sure.

>>
>> Slide 13: The bullet "Use some 'discard' next header value?" is one
>> option, but it eliminates the possibility of carrying a payload snippet
>> before the OAM message.  The other option is an explicit OAM bit (which
>> several headers have).
>I've reworded as
>*Use some ³discard² next header value, or OAM bit?

OK.

>
>*Note that I'm not sure the discussed OAM bit means the same to
>everybody.**

Hmmm.  Well it would be good to find out then :-)

>>
>> Slide 18: Loose -> Lose
>Fixed.
>>
>> Slide 24: Why is there a question mark after "WG document"?  We already
>> have a document.  Maybe this is to remind you to put the draft name?
>The DT output is a personal document. I don't know (and haven't asked
>Alia) whether her intent was to have the RTGWG pick this up as a WG
>document and review it. Hence asking the question.
>
>I made it a bit more clear:
>*RTGWG WG document? Or somewhere else?

My impression was that Alia commissioned this work (As a Routing Area AD)
- asking us to write a document...which meant that it was part of the
RTGWG.  Clarification from Alia before these slides are presented would be
good.



>
>*Thanks for your review.
>
>Erik
>
>**
>>
>>   - Larry
>>
>>
>>
>>
>>
>> On 3/10/15 6:20 PM, "Erik Nordmark" <[e-mail]> wrote:
>>
>>> See
>>> 
>>>https://docs.google.com/a/aristanetworks.com/presentation/d/1r_LpKB0tV8V
>>>JV
>>> Jx-t3h3NJagRCtIxqFXS8JesV9BCOo/edit?usp=sharing
>>>
>>> First question is whether we agree on this summary (I did it from
>>>memory)
>>> Second question is whether we should add the Hardware Friendly slide to
>>> the NVO3 slides for this Friday's presentation?
>>> It might raise some discussion.
>>>
>>>     Erik
>>>
>>> _______________________________________________
>>> Rtg-dt-encap-considerations mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations
>>
>
>_______________________________________________
>Rtg-dt-encap-considerations mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations