Subject: Re: [sfc] ***UNCHECKED*** Re: MAC Chaining and draft-homma-sfc-forwarding-methods-analysis-04

From: "Bottorff, Paul" <[email-masked]>
Date: Mon, 7 Mar 2016 19:19:53 +0000

Hi Dave:

Thank you for your review. Some comments on MAC Chaining below.

Cheers,

Paul

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Monday, March 07, 2016 6:24 AM
To: Shunsuke Homma; Fedyk, Don; Bottorff, Paul; [email-masked]
Cc: Kengo NAITO; Pearson, Mark A (HP Networking ATG)
Subject: RE: ***UNCHECKED*** Re: MAC Chaining and draft-homma-sfc-forwarding-methods-analysis-04

I see that the use of local MAC addresses is what provides the large number of chains.
Still, one must take care to administer the addresses to avoid collision with other addresses being used in the network.
PB>Agreeded, though it would be possible to allocate and manage a Global MAC addresses, using Global MACs for local assignment is discouraged by the IEEE and so is not recommended by the MAC Chaining draft.

And in some virtualization infrastructures, machines can only use MAC addresses assigned by the infrastructure.
PB> The MAC Chaining proposal allows the use of any MAC address and any assignment authority for addresses assigned to Virtual Machines, Containers, Physical middle boxes or infrastructure other than chaining SFFs. The locally assigned chain segment MACs are addresses of the SFFs. Our proposal uses an application on an OpenFlow controller to manage the Chain Segment MACs and program the SFF.

There is also the practical problem that the table size of MAC-learning switches limits the number of MAC addresses that may be used on a subnet.
PB>How many chains do you really expect? It only takes a one Chain Segment MAC per hop per chain. For 1000 chains of 10 hops this is only 10K addresses (in the entire network which could be spread over multiple switches). Learning switches routinely handle a 100K addresses and could provide much larger spaces if desired. 

And on the topic of source-address learning, I'm not clear on how a MAC-learning network will learn how to forward all of the packets without flooding? Any address used as a destination must first be used as a source address. Maybe the approach requires SDN switching vs. MAC-learning?
PB>The approach can work with ordinary learning bridges. These may use convention flooding, may use advertisements like GARPs, may be restricted using VN and VLANs, or may be controlled using SDN techniques. All of these work.

So it can't be used on just any network.
PB>It works in any conventional network and can be made to work in a variety of alternative network architecture.

You mention the pros and cons of other techniques, so I think it's fair to highlight the caveats of this technique.

-Dave

-----Original Message-----
From: Shunsuke Homma [mailto:[email-masked]]
Sent: Monday, March 07, 2016 12:26 AM
To: Fedyk, Don; Dave Dolson; Bottorff, Paul; [email-masked]
Cc: Kengo NAITO; Pearson, Mark A (HP Networking ATG)
Subject: Re: ***UNCHECKED*** Re: MAC Chaining and draft-homma-sfc-forwarding-methods-analysis-04

Hi Dave,

Certainly, overloading approach would require more MAC addresses than others, however I'm also not sure that it is an evident down-side. The number of service paths and SFs invoked in each path would not be so many in a single domain, and it would not be a critical issue.

On the other hand, I feel that it will be complex to manage addresses if overloading approach is used in multi-domain network, and some enhances for control plane, such hierarchical SFC, will be required.
#I think hSFC may be a good solution to use MAC chaining in large-scale networks.

Thanks,
Shunsuke

On 2016/03/05 9:00, Fedyk, Don wrote:
> Hi Dave
>
> This is explained in
> https://tools.ietf.org/html/draft-fedyk-sfc-mac-chain-01
>
> While it is true that there can be many MAC addresses per interface 
> MAC Chaining is less address and header space than many overlay techniques.
>
> On the SFFs and CTFs it is a unique MAC per service chain but SFs may 
> have a single fixed MAC address.  The MAC addresses are local MAC 
> addresses.
>
> Given these points I don’t see local MAC are a downside compared to 
> alternatives,
>
> Cheers,
>
> Don
>
>  > -----Original Message-----
>
>  > From: Dave Dolson [mailto:[email-masked]]
>
>  > Sent: Friday, March 04, 2016 4:41 PM
>
>  > To: Shunsuke Homma; Bottorff, Paul; 
> draft-homma-sfc-forwarding-methods-
>
>  > [email-masked]
>
>  > Cc: Kengo NAITO; Fedyk, Don; Pearson, Mark A (HP Networking ATG)
>
>  > Subject: RE: ***UNCHECKED*** Re: MAC Chaining and draft-homma-sfc-
>
>  > forwarding-methods-analysis-04
>
>  >
>
>  > Shunsuke,
>
>  > If I understand correctly, the Overlapping approach could require a 
> large
>
>  > number of MAC addresses, since a distinct address is required for 
> each
>
>  > service path, correct?
>
>  > So each interface requires an address per path?
>
>  >
>
>  > Do you mention this down-side?
>
>  >
>
>  >
>
>  > -Dave
>
>  >
>
>  >
>
>  > -----Original Message-----
>
>  > From: Shunsuke Homma [mailto:[email-masked]]
>
>  > Sent: Wednesday, January 06, 2016 8:34 PM
>
>  > To: Bottorff, Paul; draft-homma-sfc-forwarding-methods-
> <mailto:[email-masked]>
>
>> [email-masked]  
>> <mailto:[email-masked]>
>
>  > Cc: Kengo NAITO; Fedyk, Don; Pearson, Mark A (HP Networking ATG)
>
>  > Subject: ***UNCHECKED*** Re: MAC Chaining and draft-homma-sfc-
>
>  > forwarding-methods-analysis-04
>
>  >
>
>  > Hi Paul and authors,
>
>  >
>
>  > I'm really sorry for taking long time to update the 
> draft-homma-sfc-
>
>  > forwarding-methods-analysis. I was very busy in the last two months...
>
>  >
>
>  > I added the concept of MAC Chaining to the draft. The updated part 
> is
>
>  > described as "overlapping approach" in section 3.1.3 and 4.1.3. I 
> attached the
>
>  > draft on this email, and so please check the updated sections.
>
>  > The password is the date of today.(yyyymmdd)
>
>  >
>
>  > # As a result of considering features of overlapping approach, I 
> separated it
>
>  > from other approaches in method3.
>
>  >
>
>  > If you have any opinions, please let me know. I will reflect them 
> on the draft.
>
>  > I would like to upload it within the next week.
>
>  >
>
>  > Thank you for your cooperation.
>
>  > Best regards,
>
>  > Shunsuke
>
>  >
>
>  >
>
>  > On 2015/11/01 10:25, Bottorff, Paul wrote:
>
>  > > Hi Shunsuke:
>
>  > >
>
>  > > I'm happy with this resolution.
>
>  > >
>
>  > > Cheers,
>
>  > >
>
>  > > Paul
>
>  > >
>
>  > > -----Original Message-----
>
>  > > From: Shunsuke Homma [mailto:[email-masked]]
>
>  > > Sent: Friday, October 30, 2015 12:04 AM
>
>  > > To: Bottorff, Paul; DIEGO LOPEZ GARCIA
>
>  > > Cc: Kengo NAITO; [email-masked] 
> <mailto:[email-masked]>;
>
>  > [email-masked] <mailto:[email-masked]>;
>
>  > > [email-masked] <mailto:[email-masked]>; Fedyk, Don; 
> Pearson, Mark A (HP Networking
>
>  > ATG)
>
>  > > Subject: Re: MAC Chaining and
>
>  > > draft-homma-sfc-forwarding-methods-analysis-04
>
>  > >
>
>  > > Hi Paul,
>
>  > >
>
>  > > I can understand your opinion. Certainly, there are some 
> differences
>
>  > between MAC chaining and other inserting approaches in forwarding
>
>  > process. MAC chaining uses service identifiers as forwarding 
> headers, and so
>
>  > it does not require any other forwarding mechanisms. However I 
> assume
>
>  > that service chaining is generally required to use appropriate 
> forwarding
>
>  > techniques depending on underlay networks (for example, MAC 
> chaining can
>
>  > be used in only L2 network basically, and any tunnel will be 
> required when an
>
>  > SFF forwards packets over L3 network.), and fundamental processes 
> of SFF
>
>  > will be common to inserting approaches including MAC chaining.
>
>  > >
>
>  > > Therefore, I intend to add classification and analysis of 
> "inserting into an
>
>  > address field"  as one of variations of inserting approach. I 
> assume that
>
>  > "inserting into an address field" approach has the following 
> features in
>
>  > addition to other inserting approaches.
>
>  > >
>
>  > > - don't require additional forwarding techniques unless using in 
> other
>
>  > > layer network
>
>  > > - require configuration to each hop
>
>  > > - the address field is changed at each hop (lose the original 
> address
>
>  > > information)
>
>  > > - provide static paths
>
>  > >
>
>  > > Do you have any other opinions about the above?
>
>  > >
>
>  > > Thanks,
>
>  > > Shunsuke
>
>  > >
>
>  > >
>
>  > > On 2015/10/30 2:56, Bottorff, Paul wrote:
>
>  > >> Hi Shunsuke:
>
>  > >>
>
>  > >> You are correct that MAC Chaining concepts are the same as the 
> inserting
>
>  > approaches.
>
>  > >>
>
>  > >> I'm not certain the unique features of MAC Chaining will be 
> apparent in
>
>  > the comparisons if the technique is lumped with the other insertion
>
>  > techniques. Unlike the other insertion methods MAC Chaining does 
> not
>
>  > require frame expansion for L3 service frame chaining. Also, unlike 
> most of
>
>  > the techniques, except MPLS chaining, it allows frame forwarding to 
> the SFF
>
>  > using existing network forwarding techniques. If you can extend the
>
>  > insertion classification while retaining the differentiating 
> features in the
>
>  > comparisons then I would be alright combining MAC Chaining with the
>
>  > inserting approaches.
>
>  > >>
>
>  > >> Cheers,
>
>  > >>
>
>  > >> Paul
>
>  > >>
>
>  > >> -----Original Message-----
>
>  > >> From: Shunsuke Homma [mailto:[email-masked]]
>
>  > >> Sent: Thursday, October 29, 2015 12:21 AM
>
>  > >> To: DIEGO LOPEZ GARCIA; Bottorff, Paul
>
>  > >> Cc: Kengo NAITO; [email-masked] 
> <mailto:[email-masked]>;
>
>  > [email-masked] <mailto:[email-masked]>;
>
>  > >> [email-masked] <mailto:[email-masked]>; Fedyk, Don; 
> Pearson, Mark A (HP Networking
>
>  > ATG)
>
>  > >> Subject: Re: MAC Chaining and
>
>  > >> draft-homma-sfc-forwarding-methods-analysis-04
>
>  > >>
>
>  > >> Hi Paul,
>
>  > >>
>
>  > >> Sorry for my late reply.
>
>  > >>
>
>  > >> Thank you for reviewing and a new suggestion! I read
>
>  > >> draft-fedyk-sfc-mac-chain-00, and I am interested in the method. 
> And
>
>  > >> I agree with you MAC chain is categorized into method3: 
> Forwarding
>
>  > >> Based on Service Chain Identifiers, because, a service 
> identifier is
>
>  > >> mapped on MAC address and SFFs decide the next hop based on the
>
>  > >> identifier in MAC chain. Also, in my understanding, in MAC 
> chain, MAC
>
>  > >> address is used for two ways, forwarding to next hop and 
> identifying
>
>  > >> applied chain. (I think it is similar as MPLS mechanism and is 
> also
>
>  > >> categorized pattern 1.)
>
>  > >>
>
>  > >> Certainly, MAC chain is different from both tagging and 
> inserting
>
>  > approaches, however I assume that its concept and features are the 
> same
>
>  > with inserting approach. Therefore, I would like to expand the 
> inserting
>
>  > approach to include methods which use existing address fields.
>
>  > >>
>
>  > >> What do you think about my thought?
>
>  > >>
>
>  > >> Thanks,
>
>  > >> Shunsuke
>
>  > >>
>
>  > >>
>
>  > >> On 2015/10/29 6:37, DIEGO LOPEZ GARCIA wrote:
>
>  > >>> Hi Paul,
>
>  > >>>
>
>  > >>> I stand corrected. I misread your previous e-mail. You’d need 
> some
>
>  > >>> kind of NAT-like mechanism at the ingress and egress points…
>
>  > >>>
>
>  > >>> (I have corrected Kengo’s address using the latest I have form 
> him)
>
>  > >>>
>
>  > >>> Be goode,
>
>  > >>>
>
>  > >>>> On 28 Oct 2015, at 13:20 , Bottorff, Paul 
> <[email-masked]
>
>  > >>>> <mailto:[email-masked]>> wrote:
>
>  > >>>>
>
>  > >>>> Hi Diego:
>
>  > >>>> What IPv6 addresses were you considering? It would be 
> necessary to
>
>  > >>>> encode both the chain and the e-e address in the frame.
>
>  > >>>> Do you have a better email for Kengo Naito? The address
>
>  > >>>> [email-masked] <mailto:[email-masked]>
>
>  > <mailto:[email-masked]>bounces.
>
>  > >>>> Cheers,
>
>  > >>>> Paul
>
>  > >>>> *From:*DIEGO LOPEZ GARCIA 
> [mailto:[email-masked]]
>
>  > >>>> *Sent:*Wednesday, October 28, 2015 10:02 AM *To:*Bottorff, 
> Paul
>
>  > >>>> *Cc:[email-masked]
>
>  > >>>> 
> <mailto:[email-masked]>;[email-masked]
>
>  > >>>> <mailto:[email-masked]>;[email-masked]
>
>  > >>>> <mailto:[email-masked]>;[email-masked]
>
>  > >>>> <mailto:[email-masked]>;[email-masked]
>
>  > >>>> <mailto:[email-masked]>; Fedyk, Don
>
>  > >>>> *Subject:*Re: MAC Chaining and
>
>  > >>>> draft-homma-sfc-forwarding-methods-analysis-04
>
>  > >>>> Hi Paul,
>
>  > >>>> That’s why I was referring to IPv6, and not to IP in general. 
> There
>
>  > >>>> are some kinds of v6 addresses that could be used in the same
>
>  > >>>> recoverable way as MAC ones… Just an initial idea that I think
>
>  > >>>> could be usable in some controlled environments.
>
>  > >>>> Be goode,
>
>  > >>>>
>
>  > >>>>       On 28 Oct 2015, at 12:48 , Bottorff, Paul
> <[email-masked]
>
>  > >>>>       <mailto:[email-masked]>> wrote:
>
>  > >>>>       Hi Diego:
>
>  > >>>>       Yes, it is possible to do an IP address insertion chaining
>
>  > >>>>       protocol. However, the down side is that IP addresses are
> not as
>
>  > >>>>       expendable as the MAC addresses since they are e-e while MACs
>
>  > are
>
>  > >>>>       only hop-hop (unless you have an L2 service like an L2VPN,
> where
>
>  > >>>>       MAC Chaining requires an additional encapsulation so the
> MACs are
>
>  > >>>>       recoverable). In the normal case chaining using IP address
>
>  > >>>>       insertion usually requires recovery of the IP addresses
>
>  > >>>>       (essentially some type of NAT).
>
>  > >>>>       Cheers,
>
>  > >>>>
>
>  > >>>>       Paul
>
>  > >>>>       *From:*DIEGO LOPEZ GARCIA
>
>  > [mailto:[email-masked]]
>
>  > >>>>       *Sent:*Wednesday, October 28, 2015 9:12 AM
>
>  > >>>>       *To:*Bottorff, Paul
>
>  > >>>>       *Cc:[email-masked]
>
>  > >>>>
>
>  > <mailto:[email-masked]>;[email-masked]
>
>  > >>>>       <mailto:[email-masked]>;[email-masked]
>
>  > >>>>       <mailto:[email-masked]>;[email-masked]
>
>  > >>>>       <mailto:[email-masked]>;[email-masked]
>
>  > >>>>       <mailto:[email-masked]>; Fedyk, Don
>
>  > >>>>       *Subject:*Re: MAC Chaining and
>
>  > >>>>       draft-homma-sfc-forwarding-methods-analysis-04
>
>  > >>>>       Hi,
>
>  > >>>>       I wonder whether a similar address insertion could be
> applicable
>
>  > >>>>       in IPv6 as well…
>
>  > >>>>
>
>  > >>>>           On 27 Oct 2015, at 18:53 , Bottorff, Paul
>
>  > >>>>           <[email-masked] <mailto:[email-masked]
> <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>
>  > wrote:
>
>  > >>>>           Hi All:
>
>  > >>>>           I was looking over
>
>  > >>>>           draft-homma-sfc-forwarding-methods-analysis-04 to see
> how to
>
>  > >>>>           integrate MAC Chaining described in
> draft-fedyk-sfc-mac-chain-
>
>  > 00.
>
>  > >>>>           MAC Chaining appears to most nearly fit in method 3,
>
>  > >>>>           Forwarding Based on Service Chain Identifiers, because
> the MAC
>
>  > >>>>           header is used to carry a chain identifier which is then
>
>  > >>>>           programmed in the FWDs. However, it does not seem to
> belong to
>
>  > >>>>           the subcategory of Tagging an extra header or of Inserting
>
>  > >>>>           into an optional field. Perhaps a third sub-category
> should be
>
>  > >>>>           added to the document for Inserting into an address.
> The text
>
>  > >>>>           for such an addition could read:
>
>  > >>>>           Inserting into an address
>
>  > >>>>           In this approach, a service chain identifier is
> inserted as
>
>  > >>>>           part of an address field of the packet frame, such as
> an L2
>
>  > >>>>           MAC address. An example of a packet with a service chain
>
>  > >>>>           identifier inserted as a MAC address is shown in Figure X.
>
>  > >>>>           Any suggestions?
>
>  > >>>>           Cheers,
>
>  > >>>>           Paul
>
>  > >>>>
>
>  > >>>>       --
>
>  > >>>>       "Esta vez no fallaremos, Doctor Infierno"
>
>  > >>>>
>
>  > >>>>       Dr Diego R. Lopez
>
>  > >>>>       Telefonica I+D
>
>  > >>>> http://people.tid.es/diego.lopez/
>
>  > >>>>
>
>  > >>>>       e-mail:[email-masked]
>
>  > >>>>       <mailto:[email-masked]>
>
>  > >>>>       Tel:    +34 913 129 041
>
>  > >>>>       Mobile: +34 682 051 091
>
>  > >>>>       ----------------------------------
>
>  > >>>>
>
>  > >>>> 
> -------------------------------------------------------------------
>
>  > >>>> -
>
>  > >>>> -
>
>  > >>>> ---
>
>  > >>>>
>
>  > >>>>       Este mensaje y sus adjuntos se dirigen exclusivamente a su
>
>  > >>>>       destinatario, puede contener información privilegiada o
>
>  > >>>>       confidencial y es para uso exclusivo de la persona o
> entidad de
>
>  > >>>>       destino. Si no es usted. el destinatario indicado, queda
>
>  > >>>>       notificado de que la lectura, utilización, divulgación y/o
> copia
>
>  > >>>>       sin autorización puede estar prohibida en virtud de la
> legislación
>
>  > >>>>       vigente. Si ha recibido este mensaje por error, le rogamos
> que nos
>
>  > >>>>       lo comunique inmediatamente por esta misma vía y proceda a su
>
>  > >>>>       destrucción.
>
>  > >>>>
>
>  > >>>>       The information contained in this transmission is
> privileged and
>
>  > >>>>       confidential information intended only for the use of the
>
>  > >>>>       individual or entity named above. If the reader of this
> message is
>
>  > >>>>       not the intended recipient, you are hereby notified that any
>
>  > >>>>       dissemination, distribution or copying of this
> communication is
>
>  > >>>>       strictly prohibited. If you have received this transmission in
>
>  > >>>>       error, do not read it. Please immediately reply to the
> sender that
>
>  > >>>>       you have received this communication in error and then
> delete it.
>
>  > >>>>
>
>  > >>>>       Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>
>  > >>>>       destinatário, pode conter informação privilegiada ou
> confidencial
>
>  > >>>>       e é para uso exclusivo da pessoa ou entidade de destino.
> Se não é
>
>  > >>>>       vossa senhoria o destinatário indicado, fica notificado de
> que a
>
>  > >>>>       leitura, utilização, divulgação e/ou cópia sem autorização
> pode
>
>  > >>>>       estar proibida em virtude da legislação vigente. Se
> recebeu esta
>
>  > >>>>       mensagem por erro, rogamos-lhe que nos o comunique
>
>  > imediatamente
>
>  > >>>>       por esta mesma via e proceda a sua destruição
>
>  > >>>>
>
>  > >>>> --
>
>  > >>>> "Esta vez no fallaremos, Doctor Infierno"
>
>  > >>>>
>
>  > >>>> Dr Diego R. Lopez
>
>  > >>>> Telefonica I+D
>
>  > >>>> http://people.tid.es/diego.lopez/
>
>  > >>>>
>
>  > >>>> e-mail:[email-masked]
>
>  > <mailto:[email-masked]>
>
>  > >>>> Tel:    +34 913 129 041
>
>  > >>>> Mobile: +34 682 051 091
>
>  > >>>> ----------------------------------
>
>  > >>>> 
> -------------------------------------------------------------------
>
>  > >>>> -
>
>  > >>>> -
>
>  > >>>> ---
>
>  > >>>>
>
>  > >>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su
>
>  > >>>> destinatario, puede contener información privilegiada o
>
>  > >>>> confidencial y es para uso exclusivo de la persona o entidad 
> de
>
>  > >>>> destino. Si no es usted. el destinatario indicado, queda 
> notificado
>
>  > >>>> de que la lectura, utilización, divulgación y/o copia sin
>
>  > >>>> autorización puede estar prohibida en virtud de la legislación
>
>  > >>>> vigente. Si ha recibido este mensaje por error, le rogamos que 
> nos
>
>  > >>>> lo comunique inmediatamente por esta misma vía y proceda a su
>
>  > destrucción.
>
>  > >>>>
>
>  > >>>> The information contained in this transmission is privileged 
> and
>
>  > >>>> confidential information intended only for the use of the
>
>  > >>>> individual or entity named above. If the reader of this 
> message is
>
>  > >>>> not the intended recipient, you are hereby notified that any
>
>  > >>>> dissemination, distribution or copying of this communication 
> is strictly
>
>  > prohibited.
>
>  > >>>> If you have received this transmission in error, do not read it.
>
>  > >>>> Please immediately reply to the sender that you have received 
> this
>
>  > >>>> communication in error and then delete it.
>
>  > >>>>
>
>  > >>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>
>  > >>>> destinatário, pode conter informação privilegiada ou 
> confidencial e
>
>  > >>>> é para uso exclusivo da pessoa ou entidade de destino. Se não 
> é
>
>  > >>>> vossa senhoria o destinatário indicado, fica notificado de que 
> a
>
>  > >>>> leitura, utilização, divulgação e/ou cópia sem autorização 
> pode
>
>  > >>>> estar proibida em virtude da legislação vigente. Se recebeu 
> esta
>
>  > >>>> mensagem por erro, rogamos-lhe que nos o comunique
>
>  > imediatamente
>
>  > >>>> por esta mesma via e proceda a sua destruição
>
>  > >>>
>
>  > >>> --
>
>  > >>> "Esta vez no fallaremos, Doctor Infierno"
>
>  > >>>
>
>  > >>> Dr Diego R. Lopez
>
>  > >>> Telefonica I+D
>
>  > >>> http://people.tid.es/diego.lopez/
>
>  > >>>
>
>  > >>> e-mail: [email-masked] 
> <mailto:[email-masked]>
>
>  > >>> Tel:    +34 913 129 041
>
>  > >>> Mobile: +34 682 051 091
>
>  > >>> ----------------------------------
>
>  > >>>
>
>  > >>>
>
>  > >>> 
> --------------------------------------------------------------------
>
>  > >>> -
>
>  > >>> -
>
>  > >>> --
>
>  > >>>
>
>  > >>> Este mensaje y sus adjuntos se dirigen exclusivamente a su
>
>  > >>> destinatario, puede contener información privilegiada o 
> confidencial
>
>  > >>> y es para uso exclusivo de la persona o entidad de destino. Si 
> no es
>
>  > >>> usted. el destinatario indicado, queda notificado de que la 
> lectura,
>
>  > >>> utilización, divulgación y/o copia sin autorización puede estar
>
>  > >>> prohibida en virtud de la legislación vigente. Si ha recibido 
> este
>
>  > >>> mensaje por error, le rogamos que nos lo comunique 
> inmediatamente
>
>  > >>> por esta misma vía y proceda a su destrucción.
>
>  > >>>
>
>  > >>> The information contained in this transmission is privileged 
> and
>
>  > >>> confidential information intended only for the use of the 
> individual
>
>  > >>> or entity named above. If the reader of this message is not the
>
>  > >>> intended recipient, you are hereby notified that any 
> dissemination,
>
>  > >>> distribution or copying of this communication is strictly prohibited.
>
>  > >>> If you have received this transmission in error, do not read it.
>
>  > >>> Please immediately reply to the sender that you have received 
> this
>
>  > >>> communication in error and then delete it.
>
>  > >>>
>
>  > >>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>
>  > >>> destinatário, pode conter informação privilegiada ou 
> confidencial e
>
>  > >>> é para uso exclusivo da pessoa ou entidade de destino. Se não é
>
>  > >>> vossa senhoria o destinatário indicado, fica notificado de que 
> a
>
>  > >>> leitura, utilização, divulgação e/ou cópia sem autorização pode
>
>  > >>> estar proibida em virtude da legislação vigente. Se recebeu 
> esta
>
>  > >>> mensagem por erro, rogamos-lhe que nos o comunique 
> imediatamente
>
>  > por
>
>  > >>> esta mesma via e proceda a sua destruição
>
>  > >>
>
>  > >>
>
>  > >> --
>
>  > >> ----------------------------------
>
>  > >> Shunsuke Homma
>
>  > >> <[email-masked] 
> <mailto:[email-masked]>>
>
>  > >> TEL: +81 422 59 3486
>
>  > >> FAX: +81 422 60 7460
>
>  > >>
>
>  > >> NTT Network Service System Labs.
>
>  > >> Musashino city, Tokyo, Japan
>
>  > >> ----------------------------------
>
>  > >>
>
>  > >>
>
>  > >>
>
>  > >>
>
>  > >>
>
>  > >>
>
>  > >
>
>  > >
>
>  > > --
>
>  > > ----------------------------------
>
>  > > Shunsuke Homma
>
>  > > <[email-masked] 
> <mailto:[email-masked]>>
>
>  > > TEL: +81 422 59 3486
>
>  > > FAX: +81 422 60 7460
>
>  > >
>
>  > > NTT Network Service System Labs.
>
>  > > Musashino city, Tokyo, Japan
>
>  > > ----------------------------------
>
>  > >
>
>  > >
>
>  > >
>
>  > >
>
>  > >
>
>  > >
>
>  >
>
>  >
>
>  > --
>
>  > ----------------------------------
>
>  > Shunsuke Homma
>
>  > <[email-masked] 
> <mailto:[email-masked]>>
>
>  > TEL: +81 422 59 3486
>
>  > FAX: +81 422 60 7460
>
>  >
>
>  > NTT Network Service System Labs.
>
>  > Musashino city, Tokyo, Japan
>
>  > ----------------------------------
>

--
----------------------------------
Shunsuke Homma
<[email-masked]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service System Labs.
Musashino city, Tokyo, Japan
----------------------------------

---

From: "Bottorff, Paul" <[email-masked]>
Date: Mon, 7 Mar 2016 20:14:27 +0000

Hi Shunsuke and Dave:

I agree that a hierarchy is highly desirable for deploying MAC Chaining over a large scale network and provides the best scaling and management solution.

Another way to handle large scale deployments is to use multiple CS-MAC Authorities mentioned in draft-fedyk-sfc-mac-chain-01 to assign CS-MACs in different regions of the network using different Authorities. Assignment of the CS-MACs in different Authorities does not need co-ordination, though the demarcation between the authorities must be co-ordinated. 

Each authority can assign from the same address pool with overlapping address assignments as long as we maintain the rule that at Authority demarcation points each Virtual Network must have a single assignment Authority. This means that an SFF sitting at the demarcation between assignment Authorities must be programmed with a rule which crosses the Authority boundaries. This rule will match a VN,CS-MAC pair from one authority and swap to a VN,CS-MAC pair in a different authority. Of course writing this rule will require a policy agreement between the coupling Authorities.

Cheers,

Paul 

-----Original Message-----
From: Shunsuke Homma [mailto:[email-masked]] 
Sent: Sunday, March 06, 2016 9:26 PM
To: Fedyk, Don; Dave Dolson; Bottorff, Paul; [email-masked]
Cc: Kengo NAITO; Pearson, Mark A (HP Networking ATG)
Subject: Re: ***UNCHECKED*** Re: MAC Chaining and draft-homma-sfc-forwarding-methods-analysis-04

Hi Dave,

Thanks,
Shunsuke