Hi Suresh,

On Thu, Sep 15, 2016 at 12:09 AM, Suresh Krishnan <
suresh.krish...@ericsson.com> 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
> 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/
>
>
>
> ----------------------------------------------------------------------
> 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?



> ----------------------------------------------------------------------
> 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.
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to