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

[Alia Atlas <[e-mail]>]

The draft is being discussed in RTGWG.  It's up to the chairs & WG to
decide about
adoption.  I'd be surprised if that doesn't happen, but if it did, we could
discuss why.

Thanks for the hard work,
Alia

On Wed, Mar 11, 2015 at 8:57 PM, Larry Kreeger (kreeger) <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> Rtg-dt-encap-considerations mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations
>