Subject: [sfc] AD review of draft-ietf-sfc-architecture-07

From: Alia Atlas <[email-masked]>
Date: Mon, 11 May 2015 10:56:09 -0400

As is usual, I have done my AD review of draft-ietf-sfc-architecture-07.  I
do apologize that it has taken so long due to other commitments.  I found a
couple minor issues that can be addresses while IETF Last Call happens and
any issues from that are handled.

I have scheduled this for the telechat on May 28.  Please address all
comments received before May 21, so that there is sufficient time for
directorate reviews.

Thank you all for the hard work.

Minor Issues:

1) I found Figure 1 to be less than useful.   It isn't clear that branching
and rejoining can occur.  It isn't clear to me what you are trying to show
in the different SFC graphs.  Could you, perhaps, say explicitly what each
is showing?  Perhaps it is:

" In the first and second graphs, the chain, based on classification, can
skip some of the SFs.  In the third graph, the chain can revisit the same
SF (7 in this example) twice."

I think you are trying to explain more things, but what isn't clear to me.
The point that there are branches and rejoining would be useful to
illustrate, in my opinion.

2) In Sec 4.4: "Further, from a privacy perspective, an SFC Egress Node is
required to ensure that any sensitive information added as part of SFC gets
removed."   Could you clarify that information may be sensitive due to
network concerns or end-customer concerns & that issues of information
exposure should also consider flow analysis?  My high-level point is that
this isn't information just sensitive to the infrastructure/network
provider and that sensitive information can be derived.

Nit:

P.14 bullet 1: "Post-SF, the traffic is returned to the SFF, and if needed
forwarded to
another SF associated with that SFF."  should be "and, if needed, is
forwarded"

Thanks,
Alia

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 12 May 2015 15:58:08 +0000

Hi, Alia,

Thanks for your review!

Rev -08, which just posted, should address your comments.

URL:            https://www.ietf.org/internet-drafts/draft-ietf-sfc-architecture-08.txt <https://www.ietf.org/internet-drafts/draft-ietf-sfc-architecture-08.txt>
Status:         https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ <https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/>
Htmlized:       https://tools.ietf.org/html/draft-ietf-sfc-architecture-08 <https://tools.ietf.org/html/draft-ietf-sfc-architecture-08>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-08 <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-08>

Thanks!

Carlos.

> On May 11, 2015, at 10:56 AM, Alia Atlas <[email-masked]> wrote:
> 
> As is usual, I have done my AD review of draft-ietf-sfc-architecture-07.  I do apologize that it has taken so long due to other commitments.  I found a couple minor issues that can be addresses while IETF Last Call happens and any issues from that are handled.
> 
> I have scheduled this for the telechat on May 28.  Please address all comments received before May 21, so that there is sufficient time for directorate reviews.
> 
> 1) I found Figure 1 to be less than useful.   It isn't clear that branching and rejoining can occur.  It isn't clear to me what you are trying to show in the different SFC graphs.  Could you, perhaps, say explicitly what each is showing?  Perhaps it is:
> 
> " In the first and second graphs, the chain, based on classification, can skip some of the SFs.  In the third graph, the chain can revisit the same SF (7 in this example) twice."
> 
> I think you are trying to explain more things, but what isn't clear to me.  The point that there are branches and rejoining would be useful to illustrate, in my opinion.
> 
> 2) In Sec 4.4: "Further, from a privacy perspective, an SFC Egress Node is required to ensure that any sensitive information added as part of SFC gets removed."   Could you clarify that information may be sensitive due to network concerns or end-customer concerns & that issues of information exposure should also consider flow analysis?  My high-level point is that this isn't information just sensitive to the infrastructure/network provider and that sensitive information can be derived.
> 
> Nit:
> 
> P.14 bullet 1: "Post-SF, the traffic is returned to the SFF, and if needed forwarded to
> another SF associated with that SFF."  should be "and, if needed, is forwarded"
> 
> Thanks,
> Alia
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 12 May 2015 13:05:25 -0400

Carlos,

Thank you for the quick response and update.   This looks good.

Alia
On May 12, 2015 11:58 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-sfc-architecture-08.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-sfc-architecture-08
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-08
>
> Thanks!
>
> Carlos.
>
> As is usual, I have done my AD review of draft-ietf-sfc-architecture-07.
> I do apologize that it has taken so long due to other commitments.  I found
> a couple minor issues that can be addresses while IETF Last Call happens
> and any issues from that are handled.
>
> 1) I found Figure 1 to be less than useful.   It isn't clear that
> branching and rejoining can occur.  It isn't clear to me what you are
> trying to show in the different SFC graphs.  Could you, perhaps, say
> explicitly what each is showing?  Perhaps it is:
>
> I think you are trying to explain more things, but what isn't clear to
> me.  The point that there are branches and rejoining would be useful to