Re: [bess] Request for WG adoption of draft-xu-bess-encaps-udp//RE: Why transform draft-xu-softwire-encaps-udp to draft-xu-bess-encaps-udp

["Adrian Farrel" <[e-mail]>]

Just for clarity on this point:

I suggested that BESS was the right place to discuss whether and how to use BGP
to indicate tunnel types.

I also observed that a code point already exists in the BGP Tunnel Encapsulation
Attribute Tunnel Types registry at
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types

Therefore the debate the WG needs to have (perhaps before debating adoption of
this document) is:

- whether the existing code point is enough for the purpose of identifying 
  MPLS-in-UDP tunnels or whether more work is needed
- whether a foo-in-UDP tunnel type should be used instead with sub-TLVs
  to identify the different cases of foo.

Adrian

> -----Original Message-----
> From: BESS [mailto:[e-mail]] On Behalf Of Xuxiaohu
> Sent: 13 February 2015 06:10
> To: Xuxiaohu; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: [bess] Request for WG adoption of draft-xu-bess-encaps-udp//RE: Why
> transform draft-xu-softwire-encaps-udp to draft-xu-bess-encaps-udp
> 
> Hi BESS WG co-chairs,
> 
> The BGP tunnel type for MPLS-in-UDP has been mentioned in the MPLS-in-UDP
> draft since the 00 version (https://tools.ietf.org/html/draft-xu-mpls-in-udp-
> 00#page-4) which was published on April 28, 2012. However, according to the WG
> consensus during the WG adoption poll period, that section of "Signaling for
> Encapsulation in UDP" was removed from the MPLS-in-UDP draft and accordingly
> it was specified in a separate draft
(https://tools.ietf.org/html/draft-xu-softwire-
> encaps-udp-00) which was published on February 12, 2013.
> 
> Adrian has suggested me to post this draft to BESS. Furthermore, Suresh has
> indicated that the Softwire WG would not be a right place for any BGP tunnel
> type related works anymore since the WG is going to shut down in the very near
> future. Hence, would you please start a WG adoption for draft-xu-bess-encaps-
> udp which is transformed from draft-xu-softwire-encaps-udp?
> 
> Best regards,
> Xiaohu
> 
> > -----Original Message-----
> > From: Xuxiaohu
> > Sent: Friday, February 13, 2015 12:13 PM
> > To: Xuxiaohu; [e-mail]
> > Cc: Softwires WG
> > Subject: RE: [bess] Why transform draft-xu-softwire-encaps-udp to
> > draft-xu-bess-encaps-udp
> >
> > Hi all,
> >
> > I noticed the following text from RFC 5512
(draft-ietf-softwire-encaps-safi):
> >
> > ****************
> > 4.2.  Protocol Type Sub-TLV
> >
> >    The protocol type sub-TLV MAY be encoded to indicate the type of the
> >    payload packets that will be encapsulated with the tunnel parameters
> >    that are being signaled in the TLV.  The value field of the sub-TLV
> >    contains a 2-octet protocol type that is one of the types defined in
> >    [IANA-AF] as ETHER TYPEs.
> >
> >    For example, if we want to use three L2TPv3 sessions, one carrying
> >    IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
> >    packets, the egress router will include three TLVs of L2TPv3
> >    encapsulation type, each specifying a different Session ID and a
> >    different payload type.  The protocol type sub-TLV for these will be
> >    IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and
> >    MPLS (protocol type = 0x8847), respectively.
> > ***************
> >
> > It seems that RFC5512 is not only talking about IP-in-GRE, but also
MPLS-in-GRE.
> >
> > I also noticed an expired IDR WG doc (see
> > https://tools.ietf.org/html/draft-ietf-idr-encaps-safi-00) which was a
> > predecessor of draft-ietf-softwire-encaps-safi. Besides, RFC5566
> > (draft-ietf-softwire-encaps-ipsec) is also originated from the Softwire WG.
> Does
> > it mean which WG should be responsible for the BGP Tunnel Encapsulation
> > Attribute related work had ever been discussed and finally determined that
the
> > Softwire WG is the right place for it?
> >
> > Best regards,
> > Xiaohu
> >
> >
> > > -----Original Message-----
> > > From: BESS [mailto:[e-mail]] On Behalf Of Xuxiaohu
> > > Sent: Friday, February 13, 2015 9:21 AM
> > > To: [e-mail]
> > > Cc: Softwires WG
> > > Subject: [bess] Why transform draft-xu-softwire-encaps-udp to
> > > draft-xu-bess-encaps-udp
> > >
> > > Hi all,
> > >
> > > According to the suggestion from Adrian as a Routing co-AD,
> > > draft-xu-softwire-encaps-udp
> > > (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp) which was
> > > posted to the Softwire WG is now posted to the BESS WG.
> > >
> > > Any comments and suggestions are welcome.
> > >
> > > Best regards,
> > > Xiaohu
> > >
> > > > -----Original Message-----
> > > > From: Xuxiaohu
> > > > Sent: Friday, February 13, 2015 8:45 AM
> > > > To: '[e-mail]'; 'Black, David'; [e-mail];
> > > > [e-mail];
> > > > [e-mail]; [e-mail]
> > > > Cc: 'Alvaro Retana'; [e-mail]; 'Loa Andersson'
> > > > Subject: RE: draft-ietf-l3vpn-end-system and draft-ietf-mpls-in-udp
> > > >
> > > > Hi Adrian,
> > > >
> > > > Thanks a lot for your response. Although RFC5512 (i.e.,
> > > > draft-ietf-softwire-encaps-safi) and RFC5566 (i.e.,
> > > > draft-ietf-softwire-encaps-ipsec) which specify the BGP Tunnel
> > > > Encapsulation Attribute Tunnel Types for GRE, L2TPv3 and IPsec
> > > > respectively are all originated from Softwire, and further the
> > > > Softwire WG co-chairs didn't state that draft-xu-softwire-encaps-udp
> > > > doesn't belong to their WG, if the BESS and Softwire WG co-chairs
> > > > could reach an agreement that any future work related to BGP Tunnel
> > > > Encapsulation Attribute should be done in the BESS WG, it looks fine
> > > > to me. I would submit the same draft to the BESS WG as
> > > draft-xu-bess-encaps-udp.
> > > >
> > > > Best regards,
> > > > Xiaohu
> > > >
> > > > > -----Original Message-----
> > > > > From: Adrian Farrel [mailto:[e-mail]]
> > > > > Sent: Thursday, February 12, 2015 10:50 PM
> > > > > To: Xuxiaohu; 'Black, David'; [e-mail];
> > > > > [e-mail];
> > > > > [e-mail]; [e-mail]
> > > > > Cc: 'Alvaro Retana'; [e-mail]; 'Loa Andersson'
> > > > > Subject: RE: draft-ietf-l3vpn-end-system and
> > > > > draft-ietf-mpls-in-udp
> > > > >
> > > > > Hello all,
> > > > >
> > > > > 1. Why softwire? That is strictly IP-in-IP with a particular
> > > > > intention of 4-over-6 and 6-over-4. Why would MPLS-in-UDP fall
> > > > > into their
> > > charter?
> > > > > You say "all the specifications for the BGP signaling for GRE,
> > > > > IPsec and etc were all defined in separate drafts belonging to the
> > > > > Softwire WG" but I see no evidence of this. The only vaguely
> > > > > related draft I can see is draft-xu-softwire-ip-in-udp which is a
> > > > > specific IP-over-UDP-over-IP mechanism about which I will reserve
> > > > > judgement except to say that I that softwire really needs yet
> > > > > another transition mechanism and that I believe IP-in-IP can be
> > > > > hashed by existing ECMP
> > > > hardware.
> > > > >
> > > > > You also referenced draft-xu-softwire-encaps-udp but I believe
> > > > > this document expired over 12 months ago. I would not say that it
> > > > > was the most substantive or technical document I have ever read
> > > > > :-)
> > > > >
> > > > > I have not removed the chairs from this thread, but I really hate
> > > > > spamming people's in-boxes.
> > > > >
> > > > > 2. While Xiaohu has correctly pointed at the current version of
> > > > > the I-D, it might be better to look at the status in the
> > > > > Datatracker via
> > > > > http://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/
> > > > > - You'll see that the status is Waiting for AD Go-Ahead::Revised
> > > > > I-D Needed which means it has completed IETF last call and is
> > > > > waiting for a
> > > > revision.
> > > > >
> > > > > 3. If you are following the BESS mailing list, you'll see that
> > > > > there is text agreed with IANA to fix the "empty" IANA considerations
> > section.
> > > > > http://www.ietf.org/mail-archive/web/bess/current/msg00233.html
> > > > > This will be in the next revision of the draft.
> > > > >
> > > > > 4. I am sure we can involve the BESS chairs any time we note some
> > > > > work that they need to do. At the moment, they may be interested
> > > > > to know there is a conversation, but I don't know that we have
> > > > > identified any actions for them. I have not removed them from this
> > > > > thread, but I really hate spamming people's in-boxes.
> > > > >
> > > > >
> > > > > I believe there are two pieces of work:
> > > > >
> > > > > A. Assign a BGP Tunnel Encapsulation Attribute Tunnel Type. This
> > > > > has already been done. No amount of effort to change documents or
> > > > > advance one document or another will change this fact. The code
> > > > > point has already been assigned. The registry is "First Come First
> > > > > Served" and no particular process was required except an
> > > > > application to IANA. No further
> > > > action is desirable.
> > > > >
> > > > > B. Specify necessary protocol work to utilise this code point.
> > > > > This is a matter for the BESS WG. They may consider that
> > > > > everything needed has already been documented, they may consider
> > > > > that they do not want to specify anything, they may consider that
> > > > > further work is needed and can be based on your I-D, they may
> > > > > consider that further work is needed and can needs a different
> > > > > starting point. The correct way to handle this is to post your I-D
> > > > > and take the discussion to the BESS
> > > mailing list.
> > > > You may ask the BESS chairs for advice.
> > > > >
> > > > >
> > > > > What am I missing here?
> > > > > What do you want to achieve and why?
> > > > >
> > > > > What action are you actually asking for?
> > > > >
> > > > > Adrian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Xuxiaohu [mailto:[e-mail]]
> > > > > > Sent: 12 February 2015 05:56
> > > > > > To: Xuxiaohu; Black, David; [e-mail];
> > > > > > [e-mail];
> > > > > > draft-ietf- [e-mail];
> > > > > > [e-mail]; softwire- [e-mail]
> > > > > > Cc: Alvaro Retana; [e-mail]; Loa Andersson
> > > > > > Subject: RE: draft-ietf-l3vpn-end-system and
> > > > > > draft-ietf-mpls-in-udp
> > > > > >
> > > > > > By the way, I think it would be better to allow the BESS and
> > > > > > Softwire WG co-chairs to be involved.
> > > > > >
> > > > > > Best regards,
> > > > > > Xiaohu
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Xuxiaohu
> > > > > > > Sent: Thursday, February 12, 2015 9:47 AM
> > > > > > > To: 'Black, David'; [e-mail]; [e-mail];
> > > > > > > '[e-mail]'
> > > > > > > Cc: Alvaro Retana; [e-mail]; 'Loa Andersson'
> > > > > > > Subject: RE: draft-ietf-l3vpn-end-system and
> > > > > > > draft-ietf-mpls-in-udp
> > > > > > >
> > > > > > > (cced to the authors of the end-system draft)
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I thinks there must be some avoidable mistaken IANA action
request.
> > > > > > > The IANA Considerations of the latest version of the
> > > > > > > end-system draft
> > > > > > > (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-04#pa
> > > > > > > ge
> > > > > > > -2
> > > > > > > 1)
> > > > > > > which
> > > > > > was
> > > > > > > published on October 2, 2014 clearly states that " This
> > > > > > > document has no IANA actions." Furthermore, the -03 version
> > > > > > > (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03)
> > > > > > > which was published on September 18, 2014 and all the previous
> > > > > > > versions didn't mention the BGP tunnel type matter at all. On
> > > > > > > the contrary, the BGP tunnel type for MPLS-in-UDP has been
> > > > > > > mentioned since the
> > > > > > > 00 version of the MPLS-in-UDP draft
> > > > > > > (https://tools.ietf.org/html/draft-xu-mpls-in-udp-00#page-4)
> > > > > > > which was published April 28, 2012. However, According to the
> > > > > > > WG consensus during the WG adoption poll period, that section
> > > > > > > about "Signaling for Encapsulation in UDP" was removed and
> > > > > > > accordingly be specified in a separate draft
> > > > > > > (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00)
> > > > > > > which was published on February 12, 2013.
> > > > > > >
> > > > > > > Since the WG consensus during the adoption poll of the
> > > > > > > MPLS-in-UDP draft is to specify the signaling for
> > > > > > > encapsulation in UDP in a separate draft and all the
> > > > > > > specifications for the BGP signaling for GRE, IPsec and etc
> > > > > > > were all defined in separate drafts belonging to the Softwire
> > > > > > > WG, I do believe we should define
> > > > > > the
> > > > > > > signaling for UDP tunnel in a separate draft belonging to the
> > > > > > > Softwire
> > > WG.
> > > > > > >
> > > > > > > Since authors of the end-system draft believe the BGP tunnel
> > > > > > > type for MPLS-in-UDP is necessary and the MPLS-in-UDP draft is
> > > > > > > going to be published soon, the normative way is to move
> > > > > > > forward draft-xu-softwire-encaps-udp as quickly as possible, IMHO.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Xiaohu
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Black, David [mailto:[e-mail]]
> > > > > > > > Sent: Wednesday, February 11, 2015 9:58 PM
> > > > > > > > To: [e-mail]; Xuxiaohu; [e-mail]
> > > > > > > > Cc: Alvaro Retana; [e-mail]; Black, David
> > > > > > > > Subject: RE: draft-ietf-l3vpn-end-system and
> > > > > > > > draft-ietf-mpls-in-udp
> > > > > > > >
> > > > > > > > Adrian,
> > > > > > > >
> > > > > > > > Ok, that's roughly what I expected - between IANA and the
> > > > > > > > RFC Editor, the l3vpn-end-system draft will record IANA's
actions
> > here.
> > > > > > > >
> > > > > > > > I had included you as the (ir)responsible AD for the
> > > > > > > > l3vpn-end-system draft, and indeed what is transpiring is a
> > > > > > > > version of "ADs can make many
> > > > > > > things happen."
> > > > > > > >
> > > > > > > > The good news is that we don't need another draft to
> > > > > > > > allocate that BGP tunnel type code point, which was where
> > > > > > > > this whole thread started, so chalk this up as a small
> > > > > > > > victory in the never-ending battle to reduce IESG
> > > > > > > workload ;-).
> > > > > > > >
> > > > > > > > Alvaro - welcome, and congratulations on your new role!
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > --David
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Adrian Farrel [mailto:[e-mail]]
> > > > > > > > > Sent: Wednesday, February 11, 2015 4:53 AM
> > > > > > > > > To: Black, David; 'Xuxiaohu'; [e-mail]
> > > > > > > > > Cc: Alvaro Retana; [e-mail]
> > > > > > > > > Subject: draft-ietf-l3vpn-end-system and
> > > > > > > > > draft-ietf-mpls-in-udp
> > > > > > > > >
> > > > > > > > > Hi and sorry,
> > > > > > > > >
> > > > > > > > > I should have looked more deeply *before* sending my
> > > > > > > > > previous
> > > email.
> > > > > > > > >
> > > > > > > > > Here is the resolution to IANA's issue with
> > > > > > > > > draft-ietf-l3vpn-end-system that I proposed and they accepted.
> > > > > > > > >
> > > > > > > > > We're just waiting for the authors of
> > > > > > > > > draft-ietf-l3vpn-end-system to do something.
> > > > > > > > >
> > > > > > > > > A
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Pearl Liang via RT [mailto:[e-mail]]
> > > > > > > > > > Sent: 09 December 2014 17:40
> > > > > > > > > > Cc: [e-mail]; [e-mail];
> > > > > > > > > > [e-mail];
> > > > > > > > > > draft-ietf- [e-mail]
> > > > > > > > > > Subject: [IANA #798045] IANA's comments on
> > > > > > > > > > draft-ietf-l3vpn-end-system
> > > > > > > > > >
> > > > > > > > > > Hi Adrian,
> > > > > > > > > >
> > > > > > > > > > This makes it clear whether or not that assignment needs
> > > > > > > > > > to be updated when this draft is approved for publication as
RFC:
> > > > > > > > > >
> > > > > > > > > > [[[
> > > > > > > > > > I think that might be valuable. So the IANA section should
read...
> > > > > > > > > >
> > > > > > > > > >    IANA has previously made an allocation from the "BGP
> > > > > > > > > > Tunnel
> > > > > > > > Encapsulation
> > > > > > > > > >    Attribute Tunnel Types" registry that reads:
> > > > > > > > > >
> > > > > > > > > >    Value  | Name                      | Reference
> > > > > > > > > >
--------+---------------------------+-------------------------------
> > > > > > > > > >        13  | MPLS in UDP Encapsulation |
> > > > > > > > > > [draft-ietf-l3vpn-end-system]
> > > > > > > > > >
> > > > > > > > > >    IANA is requested to change the reference to point to
> > > > > > > > > > the RFC
> > > > > number
> > > > > > > > > >    of this document when it is published.
> > > > > > > > > >
> > > > > > > > > > ]]]
> > > > > > > > > >
> > > > > > > > > > The current text  "This document has no IANA actions."
> > > > > > > > > > provides no instructions and incorrectly tell people
> > > > > > > > > > there is no actions
> > > > > requested.
> > > > > > > > > >
> > > > > > > > > > Thanks
> > > > > > > > > > ~pl
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue Dec 09 13:20:57 2014, [e-mail] wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > Replying to myself and keeping the same IANA tracking
> number.
> > > > > > > > > > >
> > > > > > > > > > > > > IESG/Authors/WG Chairs:
> > > > > > > > > > > > >
> > > > > > > > > > > > > IANA has reviewed draft-ietf-l3vpn-end-system-04.
> > > > > > > > > > > > > Authors should
> > > > > > > > > > > review
> > > > > > > > > > > > > the comments and/or questions below.  Please
> > > > > > > > > > > > > report any
> > > > > > > > > > > inaccuracies and
> > > > > > > > > > > > > respond to any questions as soon as possible.
> > > > > > > > > > > > >
> > > > > > > > > > > > > IANA's reviewer has the following comments/questions:
> > > > > > > > > > > > >
> > > > > > > > > > > > > IANA has a question about the IANA Considerations
> > > > > > > > > > > > > section of this
> > > > > > > > > > > document.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Previously, an early assignment has been made to
> > > > > > > > > > > > > support this
> > > > > > > > > > > draft. The
> > > > > > > > > > > > > original request for an assignment is below:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> <begin request=""> Contact Name:
> > > > > > > > > > > > >> Thomas Morin
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Contact Email:
> > > > > > > > > > > > >> [e-mail]
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Type of Assignment:
> > > > > > > > > > > > >> Assignement of a BGP parameter in a FCFS registry.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Registry:
> > > > > > > > > > > > >> BGP Tunnel Encapsulation Attribute Tunnel Types
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> See:
> > > > > > > > > > > > >> https://www.iana.org/assignments/bgp-parameters
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Description:
> > > > > > > > > > > > >> Needed for draft-ietf-l3vpn-end-system, to allow
> > > > > > > > > > > > >> the use of an MPLS-over-UDP encapsulation as
> > > > > > > > > > > > >> specified in
> > > > > > > > > > > > >> draft-ietf-mpls-in-
> > > > > > > > > > > udp .
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> No value has been proposed yet, next available
> > > > > > > > > > > > >> value
> > > > > > > > > > > > >> 13 would be
> > > > > > > > > > > fine.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Additional Info:
> > > > > > > > > > > > >> draft-ietf-l3vpn-end-system </end>
> > > > > > > > > > > > >
> > > > > > > > > > > > > IANA Question --> The IANA Considerations section
> > > > > > > > > > > > > said "This
> > > > > > > > > > > document has
> > > > > > > > > > > > > no IANA actions."  and, as a result, the
> > > > > > > > > > > > > assignment made through
> > > > > > > > > > > the request
> > > > > > > > > > > > > above would not be made permanent. Is this the
> > > > > > > > > > > > > author's intent? If
> > > > > > > > > > > not,
> > > > > > > > > > > could
> > > > > > > > > > > > > the draft be revised to indicate that the
> > > > > > > > > > > > > assignment made based on
> > > > > > > > > > > the
> > > > > > > > > > > request
> > > > > > > > > > > > > above be changed from an initial assignment to a
> > > > > > > > > > > > > permanent
> > > > > > > > > > > assignment.
> > > > > > > > > > >
> > > > > > > > > > > How do you mean?
> > > > > > > > > > > The registry is FCFS for which *any* document is
sufficient.
> > > > > > > > > > > The assignment has been made and is as permanent as
> > > > > > > > > > > any FCFS assignment ever is.
> > > > > > > > > > >
> > > > > > > > > > > > > Please note that IANA cannot reserve specific values.
> > > > > > > > > > > > > However,
> > > > > > > > > > > early
> > > > > > > > > > > > > allocation is available for some types of
registrations.
> > > > > > > > > > > > > For more
> > > > > > > > > > > information,
> > > > > > > > > > > > > please see RFC 7120.
> > > > > > > > > > >
> > > > > > > > > > > Yes, but this is a FCFS registry to which 7120 does
> > > > > > > > > > > not apply, and nor does "reservation of values".
> > > > > > > > > > > With FCFS the value is assigned when requested and that's
it.
> > > > > > > > > > >
> > > > > > > > > > > Now, it is a different question whether this document
> > > > > > > > > > > should ask for the registry to be updated to point to
> > > > > > > > > > > the consequent RFC instead of the I-D.
> > > > > > > > > > >
> > > > > > > > > > > I think that might be valuable. So the IANA section should
> > read...
> > > > > > > > > > >
> > > > > > > > > > >    IANA has previously made an allocation from the
> > > > > > > > > > > "BGP Tunnel Encapsulation
> > > > > > > > > > >    Attribute Tunnel Types" registry that reads:
> > > > > > > > > > >
> > > > > > > > > > >    Value  | Name                      | Reference
> > > > > > > > > > >    --------+---------------------------
> > > > > > > > > > > +-------------------------------
> > > > > > > > > > >        13  | MPLS in UDP Encapsulation |
> > > > > > > > > > > [draft-ietf-l3vpn-end-system]
> > > > > > > > > > >
> > > > > > > > > > >    IANA is requested to change the reference to point
> > > > > > > > > > > to the RFC number
> > > > > > > > > > >    of this document when it is published.
> > > > > > > > > > >
> > > > > > > > > > > Cheers,
> > > > > > > > > > > Adrian
> > > > > > > > >
> > > > >
> > >
> > > _______________________________________________
> > > BESS mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/bess
> 
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess