Re: [bess] Some comments on draft-ietf-bess-nsh-bgp-control-plane-03

[Jiangyuanlong]

You have a very exhaustive summary of the load balancing scenarios:)
Thanks a lot for taking time to resolve the comments and putting the case into 
your work list.

Cheers,
Yuanlong

From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Monday, July 02, 2018 4:19 PM
To: Jiangyuanlong ; bess@ietf.org
Subject: RE: Some comments on draft-ietf-bess-nsh-bgp-control-plane-03

Ah, got it. Sorry for being dim.

In fact, there are four load balancing scenarios:
- Classifier balances across SFPs
- SFF balances across locally-attached SFIs
- SFF balances across downstream SFFs to reach downstream SFIs
- SFF balances across locally-attached SFIs *and* downstream SFFs to reach 
downstream SFIs

This last case is the one you are adding to the discussion, and it is valid..

We've missed the cut-off for updating a new version before IETF-102, but I've 
added it to my work list for this draft.

Thanks,
Adrian

From: Jiangyuanlong [mailto:jiangyuanl...@huawei.com]
Sent: 02 July 2018 07:27
To: adr...@olddog.co.uk; 
bess@ietf.org
Subject: RE: Some comments on draft-ietf-bess-nsh-bgp-control-plane-03


Dear Adrian,



Thank you for your prompt reply.

I totally agree with you that "load balancing in SFC is something that has to 
be done carefully to avoid packet ordering issues and protect stateful SF 
processing.

That basically means that load balancing decisions need to be made with SFP and 
flow awareness."

How to do load balancing with SFPs is more clearly described in your document, 
but how to enable flow awareness for load balancing is less obvious.



I think the examples in 8.9.3 and 8.9.4 only show load balancing on parallel 
SFFs, not on serial SFFs as in the following example:



 --

| SFIb |

|SFT=42|

 --

  --  --   |

 | SFI  || SFIa |  -

 |SFT=41||SFT=42| |   SFF5  |

  --  --..|192.0.2.5|..

   \/ ..:  -  :..

  - .: :.-

   --|   SFF1  |--/  - |   SFF3  |

   -->|Class-|...|192.0.2.1||   SFF6  ||192.0.2.3|-->

   -->| ifier|- |192.0.2.6|:-

   --  -  |

   |--

 --| SFI  |

| SFIc |   |SFT=43|

|SFT=42|--

 --



As shown above, SFIa, SFIb and SFIc are attached to SFF1, SFF5, and SFF6 
respectively.

Similarly, it is valid to use load balancing on SFPs or flows in this case.



Cheers,

Yuanlong

From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Sunday, July 01, 2018 4:19 PM
To: Jiangyuanlong mailto:jiangyuanl...@huawei.com>>; 
bess@ietf.org
Subject: RE: Some comments on draft-ietf-bess-nsh-bgp-control-plane-03


Hey Yuanlong,



Thanks for your thoughtful comments.



> I had a review of draft-ietf-bess-nsh-bgp-control-plane-03, thank you for 
> this useful

> document and hope it can progress quickly.

>

> In my opinion, this version still has some ambiguities which need to be 
> cleaned up:

>

> 1. In Section 3.1.1, it firstly says:" The SFI Pool Identifier is encoded as 
> an 8 octet

>  value as shown in Figure 4."  However, it then says in the end of this 
> subsection:

> "The SFI Pool Identifier is a six octet, globally unique value encoded in 
> network

>  byte order." These two sentences are confusing.



Yes. Confusion.



The 8 is supposed to refer to the whole extended community, while the 6 refers 
to the SPI Pool Identifier field.



I will clean this up.



> The 1st occurrence of SFI Pool Identifier shall be fully spelled out as "SFI 
> Pool

> Identifier extended community". Furthermore, "SPI Pool Identifier" in Figure 4

> seems to be "SFI Pool Identifier" as there is no definition for the former 
> term in

> the document. There are "SPI Pool Identifier" in other sections need to be

> consistent as well, such as "SPI Pool Identifier" in the last paragraph of 
> Section

> 3.2.1.3.



Oh, thanks!



>  2. The definitions of "Service Function Type" in Figure 3 and Figure 9 are

>   different and ambiguous. Maybe it can be simply defined as "The 
> identifier

>   for a type of service function".



Hmmm, yes the text in 3.1 and 3.2.1.3 is all mixed up! We can't tell the 
difference between an RD and a pool identifier!



> 3. "SFIR-RD List" in Figure 9 may be replaced with "SFIR-RD/SFI pool ID

Re: [bess] Some comments on draft-ietf-bess-nsh-bgp-control-plane-03

[Adrian Farrel]

Ah, got it. Sorry for being dim.
 
In fact, there are four load balancing scenarios:
- Classifier balances across SFPs
- SFF balances across locally-attached SFIs
- SFF balances across downstream SFFs to reach downstream SFIs
- SFF balances across locally-attached SFIs *and* downstream SFFs to reach
downstream SFIs
 
This last case is the one you are adding to the discussion, and it is valid.
 
We've missed the cut-off for updating a new version before IETF-102, but I've
added it to my work list for this draft.
 
Thanks,
Adrian
 
From: Jiangyuanlong [mailto:jiangyuanl...@huawei.com] 
Sent: 02 July 2018 07:27
To: adr...@olddog.co.uk; bess@ietf.org
Subject: RE: Some comments on draft-ietf-bess-nsh-bgp-control-plane-03
 
Dear Adrian,
 
Thank you for your prompt reply.
I totally agree with you that "load balancing in SFC is something that has to be
done carefully to avoid packet ordering issues and protect stateful SF
processing.
That basically means that load balancing decisions need to be made with SFP and
flow awareness."
How to do load balancing with SFPs is more clearly described in your document,
but how to enable flow awareness for load balancing is less obvious.
 
I think the examples in 8.9.3 and 8.9.4 only show load balancing on parallel
SFFs, not on serial SFFs as in the following example:
 
 --
| SFIb |
|SFT=42|
 --
  --  --   |
 | SFI  || SFIa |  -
 |SFT=41||SFT=42| |   SFF5  |
  --  --..|192.0.2.5|..
   \/ ..:  -  :..
  - .: :.-
   --|   SFF1  |--/  - |   SFF3  |
   -->|Class-|...|192.0.2.1||   SFF6  ||192.0.2.3|-->
   -->| ifier|- |192.0.2.6|:-
   --  -  |
   |--
 --| SFI  |
| SFIc |   |SFT=43|
|SFT=42|--
 --   
 
As shown above, SFIa, SFIb and SFIc are attached to SFF1, SFF5, and SFF6
respectively.
Similarly, it is valid to use load balancing on SFPs or flows in this case.
 
Cheers,
Yuanlong
 
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Sunday, July 01, 2018 4:19 PM
To: Jiangyuanlong ; bess@ietf.org
Subject: RE: Some comments on draft-ietf-bess-nsh-bgp-control-plane-03
 
Hey Yuanlong,
 
Thanks for your thoughtful comments.
 
> I had a review of draft-ietf-bess-nsh-bgp-control-plane-03, thank you for this
useful
> document and hope it can progress quickly.
> 
> In my opinion, this version still has some ambiguities which need to be
cleaned up:
> 
> 1. In Section 3.1.1, it firstly says:" The SFI Pool Identifier is encoded as
an 8 octet
>  value as shown in Figure 4."  However, it then says in the end of this
subsection:
> "The SFI Pool Identifier is a six octet, globally unique value encoded in
network
>  byte order." These two sentences are confusing.
 
Yes. Confusion.
 
The 8 is supposed to refer to the whole extended community, while the 6 refers
to the SPI Pool Identifier field.
 
I will clean this up.
 
> The 1st occurrence of SFI Pool Identifier shall be fully spelled out as "SFI
Pool
> Identifier extended community". Furthermore, "SPI Pool Identifier" in Figure 4
> seems to be "SFI Pool Identifier" as there is no definition for the former
term in
> the document. There are "SPI Pool Identifier" in other sections need to be
> consistent as well, such as "SPI Pool Identifier" in the last paragraph of
Section
> 3.2.1.3. 
 
Oh, thanks!
 
>  2. The definitions of "Service Function Type" in Figure 3 and Figure 9 are 
>   different and ambiguous. Maybe it can be simply defined as "The
identifier
>   for a type of service function". 
 
Hmmm, yes the text in 3.1 and 3.2.1.3 is all mixed up! We can't tell the
difference between an RD and a pool identifier!
 
> 3. "SFIR-RD List" in Figure 9 may be replaced with "SFIR-RD/SFI pool ID list",
as
> SFI pool ID is different from SFIR-RD and the list may consist of pure SFI
pool
> IDs.
 
Yes, again. As noted, 3.2.1.3 is all mixed up. 
 
> One further note is, upon processing this variable, we need to distinguish
> RD Type and SFI Pool Identifier Type, the IANA will need to take care not to
allocate 0x80XX for SFIR-RD Type.  
 
Yes, it's all a mess! Looks like we introduced the pool identifier without
enough thought :-(
What I have done for the next version is make a second sub-TLV of the Hop TLV so
that SFIs and SFI Po

Re: [bess] Some comments on draft-ietf-bess-nsh-bgp-control-plane-03

[Jiangyuanlong]

Dear Adrian,



Thank you for your prompt reply.

I totally agree with you that "load balancing in SFC is something that has to 
be done carefully to avoid packet ordering issues and protect stateful SF 
processing.

That basically means that load balancing decisions need to be made with SFP and 
flow awareness."

How to do load balancing with SFPs is more clearly described in your document, 
but how to enable flow awareness for load balancing is less obvious.



I think the examples in 8.9.3 and 8.9.4 only show load balancing on parallel 
SFFs, not on serial SFFs as in the following example:



 --

| SFIb |

|SFT=42|

 --

  --  --   |

 | SFI  || SFIa |  -

 |SFT=41||SFT=42| |   SFF5  |

  --  --..|192.0.2.5|..

   \/ ..:  -  :..

  - .: :.-

   --|   SFF1  |--/  - |   SFF3  |

   -->|Class-|...|192.0.2.1||   SFF6  ||192.0.2.3|-->

   -->| ifier|- |192.0.2.6|:-

   --  -  |

   |--

 --| SFI  |

| SFIc |   |SFT=43|

|SFT=42|--

 --



As shown above, SFIa, SFIb and SFIc are attached to SFF1, SFF5, and SFF6 
respectively.

Similarly, it is valid to use load balancing on SFPs or flows in this case.



Cheers,

Yuanlong

From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Sunday, July 01, 2018 4:19 PM
To: Jiangyuanlong ; bess@ietf.org
Subject: RE: Some comments on draft-ietf-bess-nsh-bgp-control-plane-03


Hey Yuanlong,



Thanks for your thoughtful comments.



> I had a review of draft-ietf-bess-nsh-bgp-control-plane-03, thank you for 
> this useful

> document and hope it can progress quickly.

>

> In my opinion, this version still has some ambiguities which need to be 
> cleaned up:

>

> 1. In Section 3.1.1, it firstly says:" The SFI Pool Identifier is encoded as 
> an 8 octet

>  value as shown in Figure 4."  However, it then says in the end of this 
> subsection:

> "The SFI Pool Identifier is a six octet, globally unique value encoded in 
> network

>  byte order." These two sentences are confusing.



Yes. Confusion.



The 8 is supposed to refer to the whole extended community, while the 6 refers 
to the SPI Pool Identifier field.



I will clean this up.



> The 1st occurrence of SFI Pool Identifier shall be fully spelled out as "SFI 
> Pool

> Identifier extended community". Furthermore, "SPI Pool Identifier" in Figure 4

> seems to be "SFI Pool Identifier" as there is no definition for the former 
> term in

> the document. There are "SPI Pool Identifier" in other sections need to be

> consistent as well, such as "SPI Pool Identifier" in the last paragraph of 
> Section

> 3.2.1.3.



Oh, thanks!



>  2. The definitions of "Service Function Type" in Figure 3 and Figure 9 are

>   different and ambiguous. Maybe it can be simply defined as "The 
> identifier

>   for a type of service function".



Hmmm, yes the text in 3.1 and 3.2.1.3 is all mixed up! We can't tell the 
difference between an RD and a pool identifier!



> 3. "SFIR-RD List" in Figure 9 may be replaced with "SFIR-RD/SFI pool ID 
> list", as

> SFI pool ID is different from SFIR-RD and the list may consist of pure 
> SFI pool

> IDs.



Yes, again. As noted, 3.2.1.3 is all mixed up.



> One further note is, upon processing this variable, we need to distinguish

> RD Type and SFI Pool Identifier Type, the IANA will need to take care not to 
> allocate 0x80XX for SFIR-RD Type.



Yes, it's all a mess! Looks like we introduced the pool identifier without 
enough thought :-(

What I have done for the next version is make a second sub-TLV of the Hop TLV 
so that SFIs and SFI Pool Identifiers are kept separate.



> Some minor editorial comments:

> 4.  "SFRIR-RD list" in Section 4.3 is misspelling.



Yes



> 5.  s/a packets/a packet/



Yes



> 6.  s/ach subtended/as subtended/



Should be "each"



> BTW, I think it is useful to support load balancing SFs across multiple SFFs 
> as

> described in Section 5.5 of RFC 7665, this will enable a more flexible 
> deployment

> of similar service functions in multiple sites across a network, such as in 5G

> transport.

> In fact, Figure 11 in your draft already demonstrates that SF Type 41 has two

> instances attached to SFF1 and SFF2 respectivel

Re: [bess] Some comments on draft-ietf-bess-nsh-bgp-control-plane-03

[Adrian Farrel]

Hey Yuanlong,
 
Thanks for your thoughtful comments.
 
> I had a review of draft-ietf-bess-nsh-bgp-control-plane-03, thank you for this
useful
> document and hope it can progress quickly.
> 
> In my opinion, this version still has some ambiguities which need to be
cleaned up:
> 
> 1. In Section 3.1.1, it firstly says:" The SFI Pool Identifier is encoded as
an 8 octet
>  value as shown in Figure 4."  However, it then says in the end of this
subsection:
> "The SFI Pool Identifier is a six octet, globally unique value encoded in
network
>  byte order." These two sentences are confusing.
 
Yes. Confusion.
 
The 8 is supposed to refer to the whole extended community, while the 6 refers
to the SPI Pool Identifier field.
 
I will clean this up.
 
> The 1st occurrence of SFI Pool Identifier shall be fully spelled out as "SFI
Pool
> Identifier extended community". Furthermore, "SPI Pool Identifier" in Figure 4
> seems to be "SFI Pool Identifier" as there is no definition for the former
term in
> the document. There are "SPI Pool Identifier" in other sections need to be
> consistent as well, such as "SPI Pool Identifier" in the last paragraph of
Section
> 3.2.1.3. 
 
Oh, thanks!
 
>  2. The definitions of "Service Function Type" in Figure 3 and Figure 9 are 
>   different and ambiguous. Maybe it can be simply defined as "The
identifier
>   for a type of service function". 
 
Hmmm, yes the text in 3.1 and 3.2.1.3 is all mixed up! We can't tell the
difference between an RD and a pool identifier!
 
> 3. "SFIR-RD List" in Figure 9 may be replaced with "SFIR-RD/SFI pool ID list",
as
> SFI pool ID is different from SFIR-RD and the list may consist of pure SFI
pool
> IDs.
 
Yes, again. As noted, 3.2.1.3 is all mixed up. 
 
> One further note is, upon processing this variable, we need to distinguish
> RD Type and SFI Pool Identifier Type, the IANA will need to take care not to
allocate 0x80XX for SFIR-RD Type.  
 
Yes, it's all a mess! Looks like we introduced the pool identifier without
enough thought :-(
What I have done for the next version is make a second sub-TLV of the Hop TLV so
that SFIs and SFI Pool Identifiers are kept separate.
 
> Some minor editorial comments:
> 4.  "SFRIR-RD list" in Section 4.3 is misspelling.
 
Yes
 
> 5.  s/a packets/a packet/
 
Yes
 
> 6.  s/ach subtended/as subtended/
 
Should be "each"
 
> BTW, I think it is useful to support load balancing SFs across multiple SFFs
as
> described in Section 5.5 of RFC 7665, this will enable a more flexible
deployment
> of similar service functions in multiple sites across a network, such as in 5G

> transport.
> In fact, Figure 11 in your draft already demonstrates that SF Type 41 has two
> instances attached to SFF1 and SFF2 respectively, I think another example can
> be added for load balancing across multiple SFFs, such as the following:
> --
>| SFIa |
>|SFT=42|
> --
>  --  --   |
> | SFI  || SFI  |  -
> |SFT=41||SFT=42| |   SFF5  |
>  --  --..|192.0.2.5|..
>   \/ ..:  -  :..
>  - .: :.-
>   --|   SFF1  |--/  - |   SFF3  |
>   -->|Class-|...|192.0.2.1||   SFF6  ||192.0.2.3|-->
>   -->| ifier|- |192.0.2.6|:-
>   --  -  |
>   |--
> --| SFI  |
>| SFIb |   |SFT=43|
>|SFT=42|--
> --   
 
Yes, an example of load balancing is a god thing to include in the examples.
Of course, load balancing in SFC is something that has to be done carefully to
avoid packet ordering issues and protect stateful SF processing.
That basically means that load balancing decisions need to be made with SFP and
flow awareness.
This is the point made by the examples in Section 8.9, and specifically the
examples in 8.9.3 and 8.9.4.
Can you have another look at those two examples and say whether they address the
load balancing you were thinking about?
 
Thanks,
Adrian
 
 
 
 
 
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Some comments on draft-ietf-bess-nsh-bgp-control-plane-03

[Jiangyuanlong]

Hi Adrian and co-authors,



I had a review of draft-ietf-bess-nsh-bgp-control-plane-03, thank you for this 
useful document and hope it can progress quickly.

In my opinion, this version still has some ambiguities which need to be cleaned 
up:

1.  In Section 3.1.1, it firstly says:" The SFI Pool Identifier is encoded 
as an 8 octet value as shown in Figure 4."  However, it then says in the end of 
this subsection: "The SFI Pool Identifier is a six octet, globally unique value 
encoded in network byte order." These two sentences are confusing.

The 1st occurrence of SFI Pool Identifier shall be fully spelled out as "SFI 
Pool Identifier extended community". Furthermore, "SPI Pool Identifier" in 
Figure 4 seems to be "SFI Pool Identifier" as there is no definition for the 
former term in the document. There are "SPI Pool Identifier" in other sections 
need to be consistent as well, such as "SPI Pool Identifier" in the last 
paragraph of Section 3.2.1.3.

2.  The definitions of "Service Function Type" in Figure 3 and Figure 9 are 
different and ambiguous. Maybe it can be simply defined as "The identifier for 
a type of service function".

3.  "SFIR-RD List" in Figure 9 may be replaced with "SFIR-RD/SFI pool ID 
list", as SFI pool ID is different from SFIR-RD and the list may consist of 
pure SFI pool IDs. One further note is, upon processing this variable, we need 
to distinguish RD Type and SFI Pool Identifier Type, the IANA will need to take 
care not to allocate 0x80XX for SFIR-RD Type.



Some minor editorial comments:

4.  "SFRIR-RD list" in Section 4.3 is misspelling.

5.  s/a packets/a packet/

6.  s/ach subtended/as subtended/



BTW, I think it is useful to support load balancing SFs across multiple SFFs as 
described in Section 5.5 of RFC 7665, this will enable a more flexible 
deployment of similar service functions in multiple sites across a network, 
such as in 5G transport.

In fact, Figure 11 in your draft already demonstrates that SF Type 41 has two 
instances attached to SFF1 and SFF2 respectively, I think another example can 
be added for load balancing across multiple SFFs, such as the following:

 --

| SFIa |

|SFT=42|

 --

  --  --   |

 | SFI  || SFI  |  -

 |SFT=41||SFT=42| |   SFF5  |

  --  --..|192.0.2.5|..

   \/ ..:  -  :..

  - .: :.-

   --|   SFF1  |--/  - |   SFF3  |

   -->|Class-|...|192.0.2.1||   SFF6  ||192.0.2.3|-->

   -->| ifier|- |192.0.2.6|:-

   --  -  |

   |--

 --| SFI  |

| SFIb |   |SFT=43|

|SFT=42|--

 --



My 2 cents,

B.R,

Yuanlong


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess