Subject: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

From: [email-masked]
Date: Mon, 21 Sep 2015 16:25:34 +0800

Dear all,

   Here is a new draft proposed to raise an issue which may exist when MD 
Type=0x01 is mandatory.
And to motivate the further discussion about MD Type. Wish you can pay 
attention to this to 
continue the discussion and make a consensus ;)

  Thanks..

Best Wishes,
Linda Wang

[email-masked] 写于 2015/09/21 16:13:57:

> [email-masked] 
> 2015/09/21 16:13
> 
> 收件人
> 
> "Cui Wang" <[email-masked]>, "Wei Meng" 
> <[email-masked]>, "Cui Wang" <[email-masked]>, "Wei 
> Meng" <[email-masked]>, 
> 
> 抄送
> 
> 主题
> 
> New Version Notification for draft-wang-sfc-md-type-issues-00.txt
> 
> 
> A new version of I-D, draft-wang-sfc-md-type-issues-00.txt
> has been successfully submitted by Cui Wang and posted to the
> IETF repository.
> 
> Name:      draft-wang-sfc-md-type-issues
> Revision:   00
> Title:      Metadata Type Issues
> Document date:   2015-09-21
> Group:      Individual Submission
> Pages:      14
> URL:            https://www.ietf.org/internet-drafts/draft-wang-sfc-
> md-type-issues-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-wang-sfc-md-
> type-issues/
> Htmlized:       
https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-00
> 
> 
> Abstract:
>    Service function chain is the definition of an ordered set of service
>    functions.  After instantiated, the service function path is created
>    and the classified traffic is steered through the corresponding
>    service function path and then forwarded to the final destination.
>    Metadata (MD) is conveyed in SFC data plane which provides the
>    ability to exchange context information between classifiers and SFs,
>    among SFs, and between external systems and SFs.  This document is
>    motivated to state an issue when MD Type = 0x1 and discuss which
>    Metadata Type in more appropriate to be mandate in SFC data plane.
> 
>  
> 
> 
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 21 Sep 2015 10:36:54 +0000

Linda,

It seems the issue that this draft attempts to raise can be summarized with this question:

"When traffic is steered to SF3, how SF3 to correctly analyze the
   Mandatory Context Headers in NSH within the arriving traffic?"

The solution to this, however, is neither of what's presented in Sections 4.1 and 4.2. The answer is much simpler and already there: the SFP (by way of the SFP ID) provides context to understand the format of the metadata. In other words, a given SFP ID will use one of the MD formats/syntax (DC, Mobility, something else).

Thanks,

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Sep 21, 2015, at 04:26, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

   Here is a new draft proposed to raise an issue which may exist when MD Type=0x01 is mandatory.
And to motivate the further discussion about MD Type. Wish you can pay attention to this to
continue the discussion and make a consensus ;)

  Thanks..

Best Wishes,
Linda Wang

[email-masked]<mailto:[email-masked]> ?? 2015/09/21 16:13:57:

> [email-masked]<mailto:[email-masked]>
> 2015/09/21 16:13
>
> ???
>
> "Cui Wang" <[email-masked]<mailto:[email-masked]>>, "Wei Meng"
> <[email-masked]<mailto:[email-masked]>>, "Cui Wang" <[email-masked]<mailto:[email-masked]>>, "Wei
> Meng" <[email-masked]<mailto:[email-masked]>>,
>
> ??
>
> ??
>
> Htmlized:       https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-00
>
>
> Abstract:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat
>
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Sep 2015 12:56:11 -0400

First, if we are doing to assume that Service Functions will use the 
SFP-ID to disambiguate type-1 metadata in mixed environments, we should 
say that in the draft.

Second, I am a bit concerned by this proposed behavior, because we have 
been careful up till now to have the Service Functions act on metadata 
without requiring per-SFP state.  This would mark a significant shift.

yours,
Joel

On 9/21/15 6:36 AM, Carlos Pignataro (cpignata) wrote:
> The solution to this, however, is neither of what's presented in
> Sections 4.1 and 4.2. The answer is much simpler and already there: the
> SFP (by way of the SFP ID) provides context to understand the format of
> the metadata. In other words, a given SFP ID will use one of the MD
> formats/syntax (DC, Mobility, something else).
>
> Thanks,
>
> On Sep 21, 2015, at 04:26, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>
>> Dear all,
>>
>> [email-masked] <mailto:[email-masked]> 写于
>> 2015/09/21 16:13:57:
>>
>> > [email-masked] <mailto:[email-masked]>
>> > 2015/09/21 16:13
>> >
>> > 收件人
>> >
>> > "Cui Wang" <[email-masked] <mailto:[email-masked]>>,
>> "Wei Meng"
>> > <[email-masked] <mailto:[email-masked]>>, "Cui Wang"
>> <[email-masked] <mailto:[email-masked]>>, "Wei
>> > Meng" <[email-masked] <mailto:[email-masked]>>,
>> >
>> > 抄送
>> >
>> > 主题
>> >
>> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: Dave Dolson <[email-masked]>
Date: Mon, 21 Sep 2015 17:11:29 +0000

At least some service functions require per-SFP state to associate bidirectional paths to each other.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, September 21, 2015 12:56 PM
To: Carlos Pignataro (cpignata); [email-masked]
Cc: Wei Meng; [email-masked]
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Sep 2015 13:31:55 -0400

Unless we are using per-subscriber SFPs (which scalesvery badly, but you 
can do it) I would expect that association to be made on the basis of 
subscriber metadata.  In normal circumstances, the path ID is neither 
necessary nor sufficient for the service function to enable symmetry.

Even if the SFPs are at a granularity so that there are separate SFP IDs 
for helping enforce path symmetry, that will not provide the state 
needed for the service functions.  And the state that is needed for the 
service functions is, in all cases I can see, sufficeint without 
examining the SFP ID.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Mon, 21 Sep 2015 17:40:06 +0000

I might be missing something, but let's take a very simple case: a proxy SF needs to respond to a SYN packet received on a SFP with a SYN-ACK. Which SFP should the SYN-ACK be placed on?

I've been assuming there needs to be a configuration to pair up left-to-right with right-to-left SFPs, and that the C3 interface would eventually provide this.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, September 21, 2015 1:32 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]
Cc: Wei Meng; [email-masked]
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Sep 2015 13:59:26 -0400

That is an aspect that I had not considered in asking your question. 
That is not about symmetry of SFPs, but about the behavior of service 
functions which generate extra packets in each direction.

Over all, that is seriously under-specified, and we should address it.

While I don't know what answer the working group will adopt, my 
inclination is to say that such packet generation needs a classifier. 
The service function generates the packet with whatever metadata it 
wants to attach, and then hands it to a classifier to determine what to 
do with it.

Separately, I would note that even if we adopt an SFP-stateful solution 
for such service functions, I would not want the metadata handling to 
drive a requirement for such state in all service functions in order to 
understand the metadata.
Before someone argues that this would only be needed in hybrid 
deployments, I would observe that I expect service functions to be 
designed and built to work in both dedicated and hybrid deployments. 
And if MD-1 is a MUST (as it currently is written) then they all have to 
have this capability.

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 21 Sep 2015 18:06:23 +0000

We studied this issue considerably and documented the solutions we implemented here:

URL:            https://www.ietf.org/internet-drafts/draft-penno-sfc-packet-00.txt
Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-packet/
Htmlized:       https://tools.ietf.org/html/draft-penno-sfc-packet-00

Abstract:
   Service Functions (e.g., Firewall, NAT, Proxies and Intrusion
   Prevention Systems) generate packets in the reverse flow direction to
   the source of the current in-process packet/flow.  In this document
   we discuss and propose how to support this required functionality
   within the SFC framework.

On 9/21/15, 10:59 AM, "sfc on behalf of Joel M. Halpern" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Yours,
Joel

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, September 21, 2015 1:32 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

Yours,
Joel

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, September 21, 2015 12:56 PM
To: Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

yours,
Joel

It seems the issue that this draft attempts to raise can be summarized
with this question:

Thanks,

On Sep 21, 2015, at 04:26, "[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

Dear all,

      Here is a new draft proposed to raise an issue which may exist when
MD Type=0x01 is mandatory.
And to motivate the further discussion about MD Type. Wish you can pay
attention to this to
continue the discussion and make a consensus ;)

     Thanks..

Best Wishes,
Linda Wang

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> 写于
2015/09/21 16:13:57:

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
2015/09/21 16:13

收件人

"Cui Wang" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>,
"Wei Meng"
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>, "Cui Wang"
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>, "Wei
Meng" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>,

抄送

主题

Abstract:

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org
<http://tools.ietf.org>.

The IETF Secretariat

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Sep 2015 14:40:45 -0400

Thanks.  That looks like a nice coverage of the space.
Yours,
Joel

On 9/21/15 2:06 PM, Reinaldo Penno (repenno) wrote:
> On 9/21/15, 10:59 AM, "sfc on behalf of Joel M. Halpern"
> <[email-masked] <mailto:[email-masked]> on behalf of
> [email-masked] <mailto:[email-masked]>> wrote:
>
>         I might be missing something, but let's take a very simple case:
>         a proxy SF needs to respond to a SYN packet received on a SFP
>         with a SYN-ACK. Which SFP should the SYN-ACK be placed on?
>
>         I've been assuming there needs to be a configuration to pair up
>         left-to-right with right-to-left SFPs, and that the C3 interface
>         would eventually provide this.
>
>
>         To: Dave Dolson; Carlos Pignataro (cpignata);
>         [email-masked] <mailto:[email-masked]>
>         Cc: Wei Meng; [email-masked] <mailto:[email-masked]>
>             At least some service functions require per-SFP state to
>             associate bidirectional paths to each other.
>
>
>             <mailto:[email-masked]>
>             Cc: Wei Meng; [email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]>
>                     <mailto:[email-masked]>
>                     <mailto:[email-masked]> 写于
>                     2015/09/21 16:13:57:
>
>                         [email-masked]
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         2015/09/21 16:13
>
>                         收件人
>
>                         "Cui Wang" <[email-masked]
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>>,
>
>                     "Wei Meng"
>
>                         <[email-masked]
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>>, "Cui Wang"
>
>                     <[email-masked] <mailto:[email-masked]>
>                     <mailto:[email-masked]>>, "Wei
>
>                         Meng" <[email-masked]
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>>,
>
>                         抄送
>
>                         主题
>
>                         URL:
>                         https://www.ietf.org/internet-drafts/draft-wang-sfc-
>                         md-type-issues-00.txt
>                         Status:
>                         https://datatracker.ietf.org/doc/draft-wang-sfc-md-
>                         type-issues/
>                         Htmlized:
>                     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 21 Sep 2015 21:51:41 +0000

Penno,

That is an interesting problem. Thanks for documenting it.

I have a couple of questions:

-          When a packet, which can be encapsulated in various outer headers (VxLAN, SFC’s NSH, or other header), arrives at the FW ingress port, which Source Address will FW send  the “generated packets” to? Is it the most outer header’s Source address?

-          What kind of events can trigger a FW to generate packets to the source?

-          If the sequence of the Service Functions is: Web Optimization -> FW, what kind of circumstances will require the FW to generate message to traverse the “Web Optimization”?

Thank you very much.

Linda

From: sfc [mailto:[email-masked]] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, September 21, 2015 1:06 PM
To: Joel M. Halpern; Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] in-path packet generation

Abstract:

Yours,
Joel

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, September 21, 2015 1:32 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

Yours,
Joel

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, September 21, 2015 12:56 PM
To: Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

yours,
Joel

Thanks,

On Sep 21, 2015, at 04:26, "[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]><mailto:[email-masked]%3e>" <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]><mailto:[email-masked]%3e>> wrote:

Dear all,

     Thanks..

Best Wishes,
Linda Wang

收件人

"Cui Wang" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>,
"Wei Meng"
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>, "Cui Wang"
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>, "Wei
Meng" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>,

抄送

主题

Abstract:

The IETF Secretariat

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 22 Sep 2015 05:54:45 +0000

The association can be made on variety of attribute,
   A) subscriber info
   B) network info e.g. Vlan. In the diagram SF3 is rcving flows from two
different type services on two distinct interfaces.

However this can be either configured, pushed over control plane. All are
fine but it is perhaps much better to color the context payload
explicitly. I also don’t think the allocation will end with mobile and dc.

Regards
Sumandra

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 22 Sep 2015 05:58:07 +0000

On 9/21/15, 10:40 AM, "sfc on behalf of Dave Dolson" <[email-masked]
on behalf of [email-masked]> wrote:

>I might be missing something, but let's take a very simple case: a proxy
>SF needs to respond to a SYN packet received on a SFP with a SYN-ACK.
>Which SFP should the SYN-ACK be placed on?

 This depends on the next hop lookup based on path_id. I don’t think any
explicit configuration is necessary.

>left-to-right with right-to-left SFPs, and that the C3 interface would
>eventually provide this.
>
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 24 Sep 2015 07:53:44 +0000

Inline with [RP]

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 21, 2015 at 2:51 PM
To: Reinaldo Penno <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>, Dave Dolson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] in-path packet generation

Penno,

[RP] Not necessarily although is an option.  The SF might have received a packet from a SFF that is not part of the reverse path.  Generated packets received by this SFF would be dropped or punted somewhere unless the SFF has access to all RSPs.  There are other techniques to solve this problem.  I will discuss a few in the upcoming revisions of the document.

[RP] Anything that violates a firewall policy.

[RP] Right, not all reverse paths are symmetric paths.  If reverse packets should not cross web optimization it means the reverse paths is asymmetric.  Generated reverse packets follow the regular path resposes would take. If responses would bypass web optimization so will generated packets.

Thank you very much.

Linda

Cc: [email-masked]<mailto:[email-masked]>

Abstract:

Yours,
Joel

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, September 21, 2015 1:32 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

Yours,
Joel

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, September 21, 2015 12:56 PM
To: Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

yours,
Joel

Thanks,

Dear all,

     Thanks..

Best Wishes,
Linda Wang

收件人

抄送

主题

Abstract:

The IETF Secretariat

---

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Thu, 24 Sep 2015 17:50:28 +0000

On Sep 24, 2015, at 12:53 AM, Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>> wrote:

Inline with [RP]

Penno,

Here are some examples (driven by policy violation or a regular policy action):

   o  "Web Proxy" inserts an HTTP page challenging the client to login,
      in order to obtain the client's identity.  This is in response to
      a packet (likely HTTP Request) but in the opposite direction of
      the flow.

   o  "Firewall" checks an idle TCP connection by sending TCP keepalives
      to the client and/or server (known as "TCP dead connection
      detection").  This is on existing flows but not responding to a
      prior packet.

   o  "Firewall" sends ICMP error message after dropping a packet.  This
      is in response to the prior packet but on a new flow.

BTW, I just submitted a draft describing this and other network security related use cases.
https://www.ietf.org/id/draft-wang-sfc-ns-use-cases-00.txt

Regards,
-Eric

Thank you very much.

Linda

Abstract:

Yours,
Joel

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, September 21, 2015 1:32 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

Yours,
Joel

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, September 21, 2015 12:56 PM
To: Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

yours,
Joel

Thanks,

Dear all,

     Thanks..

Best Wishes,
Linda Wang

收件人

抄送

主题

Abstract:

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>
<http://tools.ietf.org<http://tools.ietf.org/>>.

The IETF Secretariat

---

From: Dave Dolson <[email-masked]>
Date: Thu, 24 Sep 2015 19:50:54 +0000

Another example of an SF generating a packet is a transparent HTTP cache, which sends content to the client without having received it from the server (it was stored locally).

From: Eric Wang (ejwang) [mailto:[email-masked]]
Sent: Thursday, September 24, 2015 1:50 PM
To: Reinaldo Penno (repenno)
Cc: Linda Dunbar; Joel M. Halpern; Dave Dolson; [email-masked]
Subject: Re: [sfc] in-path packet generation

Inline with [RP]

Penno,

Regards,
-Eric

Thank you very much.

Linda

Abstract:

Yours,
Joel

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, September 21, 2015 1:32 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

Yours,
Joel

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, September 21, 2015 12:56 PM
To: Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Cc: Wei Meng; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt

yours,
Joel

Thanks,

Dear all,

     Thanks..

Best Wishes,
Linda Wang

收件人

抄送

主题

Abstract:

The IETF Secretariat

---

From: [email-masked]
Date: Fri, 25 Sep 2015 15:01:26 +0800

Hi Carlos, Joel,

  Do you mean a given SFP ID corresponds to one type(DC, mobility…)?
If my understanding is correct, is that a waste of SFP IDs?

  For example, please allow me make a bold assumption, SFP A->B->C 
might be assigned for DC & mobility & broadband in Fixed Mobile 
Convergence,
Assigning one SFP ID is enough. However, if one SFP ID indicates one type, 

there will be three SFP IDs Assigned.

Cheers,
Wei

"sfc" <[email-masked]> 写于 2015/09/21 18:36:54:

> Sections 4.1 and 4.2. The answer is much simpler and already there: 
> the SFP (by way of the SFP ID) provides context to understand the 
> format of the metadata. In other words, a given SFP ID will use one 
> of the MD formats/syntax (DC, Mobility, something else). 
> 
> Thanks,
> 
> On Sep 21, 2015, at 04:26, "[email-masked]" <[email-masked]
> > wrote:

submission