Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Mon, Jun 25, 2018 at 02:06:26PM +0000, [e-mail] wrote:
> Hi Benjamin, 
> 
> Please see inline. 

This all looks good; just one final note inline

> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Benjamin Kaduk [mailto:[e-mail]]
> > Envoyé : vendredi 22 juin 2018 20:21
> > À : BOUCADAIR Mohamed IMT/OLN
> > Cc : The IESG; [e-mail]; Behcet Sarikaya; sfc-
> > [e-mail]; [e-mail]
> > Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with
> > DISCUSS and COMMENT)
> > 
> > 
> > On Thu, Jun 21, 2018 at 06:42:11AM +0000, [e-mail] wrote:
> > >
> > > > -----Message d'origine-----
> > > > De : Benjamin Kaduk [mailto:[e-mail]]
> > > > Envoyé : jeudi 21 juin 2018 03:45
> > > > À : The IESG
> > > > The approach described in Section 4.1.5 also seems to be incompletely
> > > > specified, in that the hSFC Flow ID semantics are not covered at all.  On
> > > > my initial reading I assumed that this field's encoding and semantics
> > were
> > > > intended to be left as entirely local matters to the lower domain,
> > avoiding
> > > > a need to specify them in this document.
> > >
> > > [Med] The semantic is local to a domain.
> > 
> > Agreed, it will not escape a single domain.
> > 
> > >   However, I'm not sure that it's
> > > > actually true, since we generally want multiple vendors to be able to
> > > > interoperate,
> > >
> > > [Med] Intermediate SFC elements do not need to understand the semantic of
> > flowID. They will handle the flowID as an opaque value.
> > 
> > Agreed.  I think it might help to call out (as is done in Section 4.1.1)
> > that if the egress IBN differs from the ingress IBN, there is a need for
> > state synchronization between those nodes.
> 
> [Med] This is the intent of "state replication mentioned in Section 4.1.1". 
> 
> I changed the text to "state synchronization mentioned in Section 4.1.1".

Ah, looking at the -10 now I finally see what you are referring to.  I
think when I first read "state timeout and replication mentioned in Section
4.1.1" I did not make the connection that it was specifically the *state*
replication as well.  Probably that's just me reading to fast, but I think
your change does increase clarity.

Thanks again,

Benjamin