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#page-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 > > > > > > > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
