Subject: [sfc] New version of draft-ietf-bess-nsh-bgp-control-plane

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Jun 2020 17:44:05 +0100

Hi SFC WG,

Just a note to let you know that we've made a new version of this draft.

We've been responding to various IESG Discusses and Comments, and to the Routing Directorate review for this draft. You can see the exchanges on the BESS list.

This revision makes all of the associated changes. There is a fairly high level of change, but we believe that the changes are not very substantive.

Please take some time to look at the diffs and shout if anything is alarming or unclear.

Many thanks,
Adrian
 
> -----Original Message-----
> From: I-D-Announce <[email-masked]> On Behalf Of
> [email-masked]
> Sent: 02 June 2020 09:05
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-14.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
> 
>          Title           : BGP Control Plane for the Network Service Header
> in Service Function Chaining
>          Authors         : Adrian Farrel
>                            John Drake
>                            Eric Rosen
>                            Jim Uttaro
>                            Luay Jalil
> 	Filename        : draft-ietf-bess-nsh-bgp-control-plane-14.txt
> 	Pages           : 68
> 	Date            : 2020-06-02
> 
> Abstract:
>     This document describes the use of BGP as a control plane for
>     networks that support Service Function Chaining (SFC).  The document
>     introduces a new BGP address family called the SFC Address Family
>     Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with
>     two route types.  One route type is originated by a node to advertise
>     that it hosts a particular instance of a specified service function.
>     This route type also provides "instructions" on how to send a packet
>     to the hosting node in a way that indicates that the service function
>     has to be applied to the packet.  The other route type is used by a
>     Controller to advertise the paths of "chains" of service functions,
>     and to give a unique designator to each such path so that they can be
>     used in conjunction with the Network Service Header defined in RFC
>     8300.
> 
>     This document adopts the SFC architecture described in RFC 7665.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-14
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
> 14
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-14
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Mon, 15 Jun 2020 12:39:00 +0000

Hi Adrian, 

I have a clarification question about this part:

==
   o  The SFIR is advertised by the node hosting the service function
                                    ^^^^^^^^^^^^ 
      instance (i.e., the SFF).
==

I guess what is meant here is that the SFF is servicing this SFI, not that the SFI is embedded in the same node as the SFF. No?

Also, you may consider updating this list: 

     40    | Network Address Translator    | [This.I-D] | Date-to-be-set
     41    | NAT44                         | [This.I-D] | Date-to-be-set
     42    | NAT64                         | [This.I-D] | Date-to-be-set
     43    | NPTv6                         | [This.I-D] | Date-to-be-set

With these types:

   o  Basic NAT44            ==> Section 2.1 of RFC 3022
   o  NAPT44                 ==> Section 2.2 of RFC 3022
   o  Destination NAT        ==> RFC 8512
   o  NAT64                  ==> RFC 6146
   o  SIIT                   ==> RFC 7915
   o  EAM                    ==> RFC 7757
   o  NPTv6                  ==> RFC 6296
   o  DS-Lite                ==> RFC 6333

Thanks. 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : mardi 2 juin 2020 18:44
> À : [email-masked]
> Objet : [sfc] New version of draft-ietf-bess-nsh-bgp-control-plane
> 
> Hi SFC WG,
> 
> We've been responding to various IESG Discusses and Comments, and to the
> Routing Directorate review for this draft. You can see the exchanges on the
> BESS list.
> 
> This revision makes all of the associated changes. There is a fairly high
> level of change, but we believe that the changes are not very substantive.
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Jun 2020 21:57:12 +0100

Hi Med,

In line...

> I guess what is meant here is that the SFF is servicing this SFI, not that
the
> SFI is embedded in the same node as the SFF. No?

Yeah. That can be clarified.
I'll hold it for completion of the IESG discussions.

>   o  Destination NAT        ==> RFC 8512

Considered, but not done :-Z

Our list was derived from RFC 7498 and RFC 8300.

It's quite likely that the list you give may need to be added, but at the
moment we don't have much push for more than we've listed. I think other
additional SFTs can be added at pretty much any time in the future.

Best,
Adrian

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Tue, 16 Jun 2020 08:05:10 +0000

Med, Adrian,
>   o  Destination NAT        ==> RFC 8512

I think the term DS-Lite  does not uniquely identify a service function, because DSlite has two components/elements B4 and AFTR, each of them implementing different functions.
Here the definitions from RFC 6333:
AFTR section 6.1 :  "An AFTR element is the combination of an IPv4-in-IPv6 tunnel endpoint and an IPv4-IPv4 NAT implemented on the same node."
B4 section 5.1 : " The B4 element is a function implemented on a dual-stack-capable node, either a directly connected device or a CPE, that creates a tunnel to an AFTR."

Also if you decide to list in this section all the possible functions for IPv4/IPv6 migration technologies other atomic function are missing, like for instance MAP BR and CE RFC 7597, RFC 7599 

Thanks
Roberta

-----Original Message-----
From: sfc <[email-masked]> On Behalf Of Adrian Farrel
Sent: Monday, June 15, 2020 10:57 PM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] New version of draft-ietf-bess-nsh-bgp-control-plane

Hi Med,

In line...

the

It's quite likely that the list you give may need to be added, but at the moment we don't have much push for more than we've listed. I think other additional SFTs can be added at pretty much any time in the future.

Best,
Adrian

---

From: <[email-masked]>
Date: Tue, 16 Jun 2020 08:14:49 +0000

Hi Roberta, 

Fully agree. What I had in mind is the AFTR part. 

I also agree that MAP BR is a good candidate item to be listed as SFT. 

That's said, I trust Adrian to do the right thing here. 

Cheers,
Med

> De : Roberta Maglione (robmgl) [mailto:[email-masked]]
> Envoyé : mardi 16 juin 2020 10:05
> À : [email-masked]; BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Objet : RE: [sfc] New version of draft-ietf-bess-nsh-bgp-control-plane
> 
> Med, Adrian,
> I think the term DS-Lite  does not uniquely identify a service function,
> because DSlite has two components/elements B4 and AFTR, each of them
> implementing different functions.
> AFTR section 6.1 :  "An AFTR element is the combination of an IPv4-in-IPv6
> tunnel endpoint and an IPv4-IPv4 NAT implemented on the same node."
> B4 section 5.1 : " The B4 element is a function implemented on a dual-
> stack-capable node, either a directly connected device or a CPE, that
> creates a tunnel to an AFTR."
> 
> 
> Also if you decide to list in this section all the possible functions for
> IPv4/IPv6 migration technologies other atomic function are missing, like
> for instance MAP BR and CE RFC 7597, RFC 7599
> 
> Thanks
> Roberta
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Tue, 16 Jun 2020 08:25:39 +0000

Thanks Med.
So in my opinion, we should probably have here AFTR and MAP BR.

Cheers
Roberta

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, June 16, 2020 10:15 AM
To: Roberta Maglione (robmgl) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [sfc] New version of draft-ietf-bess-nsh-bgp-control-plane

Hi Roberta, 

Cheers,
Med

> De : Roberta Maglione (robmgl) [mailto:[email-masked]] Envoyé : 
> mardi 16 juin 2020 10:05 À : [email-masked]; BOUCADAIR Mohamed 
> TGI/OLN; [email-masked] Objet : RE: [sfc] New version of 
> draft-ietf-bess-nsh-bgp-control-plane
> 
> Med, Adrian,
> I think the term DS-Lite  does not uniquely identify a service 
> function, because DSlite has two components/elements B4 and AFTR, each 
> of them implementing different functions.
> AFTR section 6.1 :  "An AFTR element is the combination of an 
> IPv4-in-IPv6 tunnel endpoint and an IPv4-IPv4 NAT implemented on the same node."
> IPv4/IPv6 migration technologies other atomic function are missing, 
> like for instance MAP BR and CE RFC 7597, RFC 7599
> 
> Thanks
> Roberta
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> It's quite likely that the list you give may need to be added, but at 
> the moment we don't have much push for more than we've listed. I think 
> other additional SFTs can be added at pretty much any time in the future.
> 
> Best,
> Adrian
> 

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Jun 2020 10:13:05 +0100

Thanks Roberta and Med,

The purpose here, IMHO, is not to try to make a list of every possible
Service Function Type that might be needed one day. That would be an endless
task and I do not believe I am qualified to make such guesses.

The registry is First Come First Served for this reason. Once the registry
has been created, it will be a simple matter for anyone (you included!) to
decide that additional SFTs are needed, and get them registered.

Best,
Adrian

-----Original Message-----
From: Roberta Maglione (robmgl) <[email-masked]> 
Sent: 16 June 2020 09:26
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sfc] New version of draft-ietf-bess-nsh-bgp-control-plane

Thanks Med.

Cheers
Roberta

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, June 16, 2020 10:15 AM
To: Roberta Maglione (robmgl) <[email-masked]>; [email-masked];
[email-masked]

Hi Roberta, 

Cheers,
Med

> other additional SFTs can be added at pretty much any time in the future.

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 16 Jun 2020 09:53:07 +0000

Re-, 

Fair enough and point taken. I will be registering the ones I suggested once the registry is available. 

That's said, I would remove "Network Address Translator" entry from your initial list as it overlaps with NAT44/NAT64. 

Also, having an "additional notes" or something similar to include a pointer (if available) to where the function is defined would be helpful for interoperability.   

Cheers,
Med

> De : Adrian Farrel [mailto:[email-masked]]
> Envoyé : mardi 16 juin 2020 11:13
> À : 'Roberta Maglione (robmgl)'; BOUCADAIR Mohamed TGI/OLN; [email-masked]