Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt

From: Thomas Narten <[email-masked]>
Date: Sun, 09 Nov 2014 21:18:16 -0500

Note: chair hat off.

I have a number of concerns with the document, including:

1) I don't see what significant content it has beyond what the other
WG use case documents contain.

2) Section 4.3 Talks about SFC and TE, but it is unclear to me what
this section is trying to say. Is it saying SFC needs TE? Or TE needs
SFC?  And how is that a "use case"? TE already exists. Does the
addition of SFC somehow change things?

3) Section 4.4 seems to simply say that some SFC flows are
bi-directional. That has been an assumption in SFC from the
start. Doesn't the problem statement/architecture say as much?

4) I don't understand Section 4.4. SFC operates over IP. Full
stop. I'm not sure what use case has Ethernet in it or why that is
called out. SFC can run over Ethernet so long as it is also an IP
subnet. Or is this section trying to say something else? If so, what?

5) Section 4.6 talks about service path forking. The WG has discussed
"forking" multiple times, and it's a basic part of SFC. So what
exactly is this section that isn't covered elsewhere? 

6) I don't follow or understand the "recursive SFC" section. When it
talks about different service providers,  I have to wonder how that
applies to SFC, given our scope is restricted to a single
administrative domain. But more to the point, how does "recursive"
differ from straightforward SFC usage, where different subscribers use
different service chains?

Thomas

---

From: "Changcheng Huang" <[email-masked]>
Date: Mon, 10 Nov 2014 10:05:57 -0500

Hi Thomas,

I appreciate that you clearly state your questions and concerns. This will
be very helpful for the working group to move forward. With due respect, I
have some brief comments.

1. The WG has approved three use case documents as internet-draft. However
there were still some heated discussions about service path forking, which
has not been clearly addressed by the three use case documents. This leads
to a question about whether we have really understood all important use
cases and their impacts. I share your comments on IETF's reluctance to pass
a large number of low quality RFCs. There is very little chance that these
three use cases will all become RFCs. It will also look strange for a reader
outside the WG to read three use case documents instead of one. IMHO, the WG
should generate a merged use case document that gets the supports across the
working group. To this end, this draft use case document in question can be
a good starting point. I hope, as the chair, you can help lead the WG to
reach consensus rather than majority votes as the WG has been doing. 

2. About Item 6 in your email, I know the WG has limited its scope to a
single administrative domain. This is fine if the protocols developed by
this working group can be easily extended to multiple domains in future.
However, some of the existing protocol proposals in the WG are quite rigid
and hard to extend. This will likely make those protocols short-lived. As
you said in the earlier email, it is in the best interest of this WG to
develop good quality protocols that can stand the test of time. In Section
2.9 of the problem statement document that is currently being approved by
IETF, crossing administrative boundaries is considered important for
providing end-to-end service visibility. This is a good comment for taking
the big picture into account. More information about recursive SFC can be
found in draft-huang-sfc-use-case-recursive-service-00.  

Best regards,

Chang    

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Sunday, November 09, 2014 9:18 PM
To: [email-masked]
Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt

Note: chair hat off.

1) I don't see what significant content it has beyond what the other WG use
case documents contain.

2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this
section is trying to say. Is it saying SFC needs TE? Or TE needs SFC?  And
how is that a "use case"? TE already exists. Does the addition of SFC
somehow change things?

3) Section 4.4 seems to simply say that some SFC flows are bi-directional.
That has been an assumption in SFC from the start. Doesn't the problem
statement/architecture say as much?

4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm not
sure what use case has Ethernet in it or why that is called out. SFC can run
over Ethernet so long as it is also an IP subnet. Or is this section trying
to say something else? If so, what?

5) Section 4.6 talks about service path forking. The WG has discussed
"forking" multiple times, and it's a basic part of SFC. So what exactly is
this section that isn't covered elsewhere? 

6) I don't follow or understand the "recursive SFC" section. When it talks
about different service providers,  I have to wonder how that applies to
SFC, given our scope is restricted to a single administrative domain. But
more to the point, how does "recursive"
differ from straightforward SFC usage, where different subscribers use
different service chains?

Thomas

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Ron Parker <[email-masked]>
Date: Mon, 10 Nov 2014 23:15:23 +0000

Chang,

I agree that after all is said and done with SFC, it will make much more sense for a reader to view a single use case document to provide the context as to why the architecture and protocols turned out the way they did.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Changcheng Huang
Sent: Monday, November 10, 2014 10:06 AM
To: 'Thomas Narten'
Cc: [email-masked]
Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt

Hi Thomas,

I appreciate that you clearly state your questions and concerns. This will be very helpful for the working group to move forward. With due respect, I have some brief comments.

1. The WG has approved three use case documents as internet-draft. However there were still some heated discussions about service path forking, which has not been clearly addressed by the three use case documents. This leads to a question about whether we have really understood all important use cases and their impacts. I share your comments on IETF's reluctance to pass a large number of low quality RFCs. There is very little chance that these three use cases will all become RFCs. It will also look strange for a reader outside the WG to read three use case documents instead of one. IMHO, the WG should generate a merged use case document that gets the supports across the working group. To this end, this draft use case document in question can be a good starting point. I hope, as the chair, you can help lead the WG to reach consensus rather than majority votes as the WG has been doing. 

2. About Item 6 in your email, I know the WG has limited its scope to a single administrative domain. This is fine if the protocols developed by this working group can be easily extended to multiple domains in future.
However, some of the existing protocol proposals in the WG are quite rigid and hard to extend. This will likely make those protocols short-lived. As you said in the earlier email, it is in the best interest of this WG to develop good quality protocols that can stand the test of time. In Section
2.9 of the problem statement document that is currently being approved by IETF, crossing administrative boundaries is considered important for providing end-to-end service visibility. This is a good comment for taking the big picture into account. More information about recursive SFC can be found in draft-huang-sfc-use-case-recursive-service-00.  

Best regards,

Chang    

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Sunday, November 09, 2014 9:18 PM
To: [email-masked]
Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt

Note: chair hat off.

1) I don't see what significant content it has beyond what the other WG use case documents contain.

2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this section is trying to say. Is it saying SFC needs TE? Or TE needs SFC?  And how is that a "use case"? TE already exists. Does the addition of SFC somehow change things?

3) Section 4.4 seems to simply say that some SFC flows are bi-directional.
That has been an assumption in SFC from the start. Doesn't the problem statement/architecture say as much?

4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm not sure what use case has Ethernet in it or why that is called out. SFC can run over Ethernet so long as it is also an IP subnet. Or is this section trying to say something else? If so, what?

5) Section 4.6 talks about service path forking. The WG has discussed "forking" multiple times, and it's a basic part of SFC. So what exactly is this section that isn't covered elsewhere? 

6) I don't follow or understand the "recursive SFC" section. When it talks about different service providers,  I have to wonder how that applies to SFC, given our scope is restricted to a single administrative domain. But more to the point, how does "recursive"
differ from straightforward SFC usage, where different subscribers use different service chains?

Thomas

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 10 Nov 2014 23:52:32 +0000

Hi Chang,

Some comments inline.

>reach consensus rather than majority votes as the WG has been doing.

Jim> What specifically is missing from the SFC architecture specification
that this use case document highlights?

>and hard to extend. This will likely make those protocols short-lived. As

Jim> which protocol proposals are you referring too and what specifically
is hard to extend?

---

From: Thomas Narten <[email-masked]>
Date: Mon, 10 Nov 2014 20:05:52 -0500

Hi Ron.

> I agree that after all is said and done with SFC, it will make much
> more sense for a reader to view a single use case document to
> provide the context as to why the architecture and protocols turned
> out the way they did.

But I don't see how to get there from here at this point. We've
already got two documents, three if you count the more general one,
and they'd have to be merged. More work someone has to do. And there
has never really been WG consensus for just one merged document. As a
general rule, I personally would prefer one document over many, but I
think we're past that.

And again, how much effort does the WG want to spend on use cases?
Will doing more use case work over the next few months make our
architecture/protocols better or get them completed more quickly? I
have doubts...

Thomas

---

From: "Pham, Chuong D" <[email-masked]>
Date: Tue, 11 Nov 2014 13:18:51 +1100

I also support Chang's and Ron's statements. It is strange to isolate the use cases from each domain into separate documents without any consideration for relationship, commonality and synergy between the use cases. We don't work like that over here. In fact, we used to work like that...
Chuong

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Tuesday, 11 November 2014 10:15 AM
To: [email-masked]; 'Thomas Narten'
Cc: [email-masked]
Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt

Chang,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Changcheng Huang
Sent: Monday, November 10, 2014 10:06 AM
To: 'Thomas Narten'
Cc: [email-masked]
Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt

Hi Thomas,

Best regards,

Chang    

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Sunday, November 09, 2014 9:18 PM
To: [email-masked]
Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt

Note: chair hat off.

Thomas

---

From: Kengo Naito <[email-masked]>
Date: Wed, 12 Nov 2014 01:12:15 +0900

Hi all,

IMO, I don't think it is strange to have several separate documents, as 
use cases of SFC may vary greatly in each environment.
I think it is more useful if people can read precise use case and 
considerations of each environment.
Also, each document is well written in term of this point.

Cheers,
Kengo

-- 
----------------------------------------
NTT Network Technology Laboratories
Kengo Naito
E-Mail: [email-masked]
TEL: +81 422-59-4949
----------------------------------------

---

From: "Songhaibin (A)" <[email-masked]>
Date: Thu, 13 Nov 2014 04:07:29 +0000

Agree with Ron here.

Best Regards!
-Haibin

> From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
> Sent: Tuesday, November 11, 2014 7:15 AM
> I agree that after all is said and done with SFC, it will make much more sense
> for a reader to view a single use case document to provide the context as to
> why the architecture and protocols turned out the way they did.
> 
>    Ron
> 
> 
> I appreciate that you clearly state your questions and concerns. This will be
> very helpful for the working group to move forward. With due respect, I have
> some brief comments.
> 
> there were still some heated discussions about service path forking, which has
> not been clearly addressed by the three use case documents. This leads to a
> question about whether we have really understood all important use cases and
> their impacts. I share your comments on IETF's reluctance to pass a large
> number of low quality RFCs. There is very little chance that these three use
> cases will all become RFCs. It will also look strange for a reader outside the WG
> to read three use case documents instead of one. IMHO, the WG should
> generate a merged use case document that gets the supports across the
> working group. To this end, this draft use case document in question can be a
> good starting point. I hope, as the chair, you can help lead the WG to reach
> consensus rather than majority votes as the WG has been doing.
> 
> 2. About Item 6 in your email, I know the WG has limited its scope to a single
> administrative domain. This is fine if the protocols developed by this working
> group can be easily extended to multiple domains in future.
> However, some of the existing protocol proposals in the WG are quite rigid and
> hard to extend. This will likely make those protocols short-lived. As you said in
> the earlier email, it is in the best interest of this WG to develop good quality
> protocols that can stand the test of time. In Section
> IETF, crossing administrative boundaries is considered important for providing
> end-to-end service visibility. This is a good comment for taking the big picture
> into account. More information about recursive SFC can be found in
> draft-huang-sfc-use-case-recursive-service-00.
> 
> Best regards,
> 
> Chang
> 
> 2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this section is
> trying to say. Is it saying SFC needs TE? Or TE needs SFC?  And how is that a
> "use case"? TE already exists. Does the addition of SFC somehow change
> things?
> 
> 4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm not sure
> what use case has Ethernet in it or why that is called out. SFC can run over
> Ethernet so long as it is also an IP subnet. Or is this section trying to say
> something else? If so, what?
> 
> 5) Section 4.6 talks about service path forking. The WG has discussed "forking"
> multiple times, and it's a basic part of SFC. So what exactly is this section that
> isn't covered elsewhere?
> 
> 6) I don't follow or understand the "recursive SFC" section. When it talks about
> different service providers,  I have to wonder how that applies to SFC, given
> our scope is restricted to a single administrative domain. But more to the point,
> how does "recursive"

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Thu, 20 Nov 2014 17:26:19 +0000

Hi Thomas,

Thank you for your comments. Please see my reply to part of your comments inline below.

Cheers,
Will

> Sent: Sunday, November 09, 2014 7:18 PM
> To: [email-masked]
> 3) Section 4.4 seems to simply say that some SFC flows are bi-directional. That
> has been an assumption in SFC from the start. Doesn't the problem

[Will] Given the forking case is a basic one in our group, IMHO, we may need to show it in our output to those who were not in this group from the very beginning and missed the discussion. WGs of IETF conclude and we cannot expect the future readers go through the mailing list. We've checked draft-ietf-sfc-dc-use-cases-01 and draft-ietf-sfc-use-case-mobility-01, however, it seems that the forking case has not been fully covered yet. Fig 6 in mobility draft only touched a little about this, however, it failed in explaining the details of forking to readers.

Another thing that should be point out, which is not mentioned in this thread, is the SFC over Multiple Underlay Networks case has not been covered yet in any of the existing WG use case drafts.