[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

[Xuxiaohu <[e-mail]>]

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