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:[email protected]] On Behalf Of Xuxiaohu > Sent: 13 February 2015 06:10 > To: Xuxiaohu; [email protected]; [email protected] > Cc: [email protected]; [email protected] > 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; [email protected] > > 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:[email protected]] On Behalf Of Xuxiaohu > > > Sent: Friday, February 13, 2015 9:21 AM > > > To: [email protected] > > > 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: '[email protected]'; 'Black, David'; [email protected]; > > > > [email protected]; > > > > [email protected]; [email protected] > > > > Cc: 'Alvaro Retana'; [email protected]; '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:[email protected]] > > > > > Sent: Thursday, February 12, 2015 10:50 PM > > > > > To: Xuxiaohu; 'Black, David'; [email protected]; > > > > > [email protected]; > > > > > [email protected]; [email protected] > > > > > Cc: 'Alvaro Retana'; [email protected]; '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:[email protected]] > > > > > > Sent: 12 February 2015 05:56 > > > > > > To: Xuxiaohu; Black, David; [email protected]; > > > > > > [email protected]; > > > > > > draft-ietf- [email protected]; > > > > > > [email protected]; softwire- [email protected] > > > > > > Cc: Alvaro Retana; [email protected]; 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'; [email protected]; [email protected]; > > > > > > > '[email protected]' > > > > > > > Cc: Alvaro Retana; [email protected]; '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:[email protected]] > > > > > > > > Sent: Wednesday, February 11, 2015 9:58 PM > > > > > > > > To: [email protected]; Xuxiaohu; [email protected] > > > > > > > > Cc: Alvaro Retana; [email protected]; 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:[email protected]] > > > > > > > > > Sent: Wednesday, February 11, 2015 4:53 AM > > > > > > > > > To: Black, David; 'Xuxiaohu'; [email protected] > > > > > > > > > Cc: Alvaro Retana; [email protected] > > > > > > > > > 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:[email protected]] > > > > > > > > > > Sent: 09 December 2014 17:40 > > > > > > > > > > Cc: [email protected]; [email protected]; > > > > > > > > > > [email protected]; > > > > > > > > > > draft-ietf- [email protected] > > > > > > > > > > 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, [email protected] 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: > > > > > > > > > > > > >> [email protected] > > > > > > > > > > > > >> > > > > > > > > > > > > >> 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/bess > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
