Hi Adrian,

Yes it is ready, we will proceed with the shepherd's review. However, we don't 
have any sign of implementation or roadmap yet, we (chairs) will have to ask 
the WG to determine a consensus to progress the document without an 
implementation (as per our implementation policy).

In addition, I missing the IPR poll reply from: Jim, Eric, Stuart, Keyur, 


-----Original Message-----
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, February 25, 2019 18:39
To: bess@ietf.org
Subject: Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.txt


Thanks for the comments we received during WG last call.

John and I have also re-reviewed the entire text.

We made a small number of little changes resulting from these activities.

Chairs: I think we are ready to move forward.


-----Original Message-----
From: I-D-Announce <i-d-announce-boun...@ietf.org> On Behalf Of
Sent: 25 February 2019 17:20
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

        Title           : BGP Control Plane for NSH SFC
        Authors         : Adrian Farrel
                          John Drake
                          Eric Rosen
                          Jim Uttaro
                          Luay Jalil
        Filename        : draft-ietf-bess-nsh-bgp-control-plane-06.txt
        Pages           : 55
        Date            : 2019-02-25

   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 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.

   This document adopts the SFC architecture described in RFC 7665.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

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:

I-D-Announce mailing list
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

BESS mailing list


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.

BESS mailing list

Reply via email to