Hi Alia,

On 09/15/2016 09:21 AM, Alia Atlas wrote:
> Hi Suresh,
>
> On Thu, Sep 15, 2016 at 12:09 AM, Suresh Krishnan
> <[email protected] <mailto:[email protected]>> wrote:
>
>     Suresh Krishnan has entered the following ballot position for
>     draft-ietf-nvo3-arch-07: Discuss
>
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
>
>
>     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     for more information about IESG DISCUSS and COMMENT positions.
>
>
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/
>     <https://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/>
>
>
>
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>
>     * Section 3.1.2 : I am trying to understand why a minimum TTL decrement
>     is expected here. I think the mandated behavior is incorrect and needs to
>     be fixed.
>
>        For L3 service, Tenant Systems should expect the IPv4 TTL (Time to
>        Live) or IPv6 Hop Limit in the packets they send to be decremented by
>        at least 1.
>
>     e.g. Consider two IPv6 end systems that are connected using an L3
>     service. If one of them is the router and another is a host on the same
>     network a significant part of the Neighbor Discovery functions will stop
>     working if the hop limit is decremented (from 255 to 254).
>
>
> The tenant systems are connected across a cloud that is viewed as containing
> at least one router in them.  If an L3 service is offered, then the 
> architecture
> expects that the tenant systems are connected to at least one router.    Not
> requiring a TTL decrement would make it look like the tenant systems were
> connected on the same L2 segment.
>
> The tenant systems are expected to be hosts, not routers.  Does that help?

Yes. Absolutely. I did not get that from the description in the draft 
earlier, but that makes sense.

>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     * For an architecture based on tunnels I found the lack of discussion
>     concerning MTUs and fragmentation a bit disconcerting. Has the WG
>     discussed this?
>
>
> Yes - standard discussion about understanding the size of the header and
> setting the MTU accordingly.  There is also an individual draft talking about
> MTU discovery
> and how to pass that info on, but not adopted as a  WG item.

Great.

Thanks
Suresh


_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to