Re: [nvo3] Suresh Krishnan's Discuss on draft-ietf-nvo3-arch-07: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

Hi, David and Alia,

On Thu, Sep 15, 2016 at 8:25 AM, Black, David  wrote:

> Hi Suresh,
>
> Regarding your 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).
>
> In that example, the two IPV6 end systems need to be connected by a
> virtual link that provides L2 service, e.g. to make ND and ARP work.   Do
> you  have suggestions for text to add (and where to add it) that would
> make this clearer?
>
> > * For an architecture based on tunnels I found the lack of discussion
> > concerning MTUs and fragmentation a bit disconcerting. Has the WG
> > discussed this?
>
> Well, IMHO,  observing the intarea WG's level of engagement here, I
> don't think more "cooks" are needed on this topic .   It'd be reasonable
> to add a sentence on this topic pointing to the intarea tunnels draft.
>
> Thanks, --David
>

Thanks to both of you for helping me understand this better.

Spencer
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Spencer Dawkins' No Objection on draft-ietf-nvo3-arch-07: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, David,

On Sep 19, 2016 18:55, "Black, David"  wrote:
>
> Hi Spencer,
>
> Thanks for the careful read.
>
> > I couldn't parse
> >
> >L3 VN to Legacy L2:  This type of gateway forwards packets on between
> >  L3 VNs and legacy L2 networks such as VLANs or L2 VPNs.  The
> >  MAC address in any frames forwarded between the legacy L2
> >  ^
> >  network would be the MAC address of the gateway.
> >  ^^^
> >
> > I could guess, but something is borked, and I'm not sure what is meant.
>
> Yes, it's definitely borked.  Latter sentence rewritten to:
>
>The sender's destination MAC address in any frames that the gateway
forwards from a legacy L2 network would be the MAC address of the gateway.
>
> The reverse direction case (gateway MAC is source MAC for frames
forwarded to a legacy L2 network) can be inferred from that statement, so I
haven't added text for that case.  I did make corresponding wording changes
to two other bullets  - well, at least the borking was consistent  ;-).
>
> > further down.
> >
> > I know what "hard" and "soft" errors are in my world, but I'm not sure
> > what's meant here.
>
> That distinction is not important in this draft (e.g., it's not used
elsewhere in the draft), so I removed it and combined the two bullets into:
>
>   o  Delivered to correct NVE, but could not deliver packet to TS-X.
>
> > Is
> >
> >o  Allow different protocols and architectures to be used to for
> >  ^^ ^^^
> >   intra- vs. inter-NVA communication.
> >
> > just a typo, or is there something missing between "to" and "for"?
>
> Yes, it's just a typo I changed: "used to for" -> "used for"
>
> Thanks, --David

This all looks fine to me. Thanks for the quick response!

Spencer

> > -Original Message-
> > From: Spencer Dawkins [mailto:spencerdawkins.i...@gmail.com]
> > Sent: Thursday, September 15, 2016 9:42 AM
> > To: The IESG
> > Cc: draft-ietf-nvo3-a...@ietf.org; Matthew Bocci; nvo3-cha...@ietf.org;
> > matthew.bo...@alcatel-lucent.com; nvo3@ietf.org
> > Subject: Spencer Dawkins' No Objection on draft-ietf-nvo3-arch-07: (with
> > COMMENT)
> >
> > Spencer Dawkins has entered the following ballot position for
> > draft-ietf-nvo3-arch-07: No Objection
> >
> > 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/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > I found a small number of nits that I couldn't error-correct while
> > reading, but I'm especially interested in Suresh's Discuss on TTL
> > decrementing.
> >
> > I couldn't parse
> >
> >L3 VN to Legacy L2:  This type of gateway forwards packets on between
> >  L3 VNs and legacy L2 networks such as VLANs or L2 VPNs.  The
> >  MAC address in any frames forwarded between the legacy L2
> >  ^
> >  network would be the MAC address of the gateway.
> >  ^^^
> >
> > I could guess, but something is borked, and I'm not sure what is meant.
> >
> > I'm having the same problem with
> >
> >L3 VN to L2 VN:  This type of gateway forwards packets on between L3
> >  VNs and L2 VNs.  The MAC address in any frames forwarded
> >  between the L2 VN would be the MAC address of the gateway.
> >  ^
> >
> > further down.
> >
> > I know what "hard" and "soft" errors are in my world, but I'm not sure
> > what's meant here.
> >
> >o  Delivered to correct NVE, but could not deliver packet to TS-X
> >   (soft error).
> >
> >o  Delivered to correct NVE, but could not deliver packet to TS-X
> >   (hard error).
> >
> > Are these clearly understood terms of art in NV03? If not, could you
> > provide some parenthetical "i.e.", as you do for other items in the same
> > list, or some reference if an appropriate reference exists?
> >
> > Is
> >
> >o  Allow different protocols and architectures to be used to for
> >  ^^ ^^^
> >   intra- vs. inter-NVA communication.
> >
> > just a typo, or is there something missing between "to" and "for"?
> >
>
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] [Tsv-art] Tsvart last call review of draft-ietf-nvo3-vmm-04

[Spencer Dawkins at IETF]

If I might offer an opinion here ...

On Fri, Sep 14, 2018 at 9:26 AM Behcet Sarikaya 
wrote:

>
>
> On Thu, Sep 13, 2018 at 8:03 PM Black, David  wrote:
>
>> > #. It does not seem as if the NVO WG has discussed the purpose of
>> using normative text in this draft. See detailed comments.
>>
>>
>>
>> > [Linda] The “Intended status” of the draft is “Best Current Practice”.
>> So all the text are not “normative”. Is it Okay?
>>
>>
>>
>> Not really – this draft might be better targeted as “Informational” as it
>> is not a comprehensive review of current practice (best or otherwise) nor
>> an overall set of recommendations, e.g., as Bob wrote “it just asserts what
>> appears to be one view of how a whole VM Mobility system works.”
>>
>>
>>
>
>
> At present we have no intention of changing the intended status because
> that decision should be deferred until IESG Review where we expect to
> receive an authoritative view.
>

Right -  this is pretty clear in
https://tools.ietf.org/html/rfc2026#section-6.1.2. The IESG is supposed to
make sure the status coming out makes sense, whether the intended status
going in made sense or not.

Having said that, I would encourage people to take their best shot at
recommending the intended status going into IESG Review, because having 15
people who haven't thought about the intended status as much as other
people should have, trying to figure that out during a telechat week makes
more sense if the document comes in with an obviously inappropriate
intended status - if you can send a document with an appropriate intended
status, the document is more likely to come out with the right status, in
my experience.

Do the right thing, of course!

Spencer
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3