Hi Adrian, > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Adrian Farrel > Sent: Sunday, February 15, 2015 9:01 AM > To: [email protected] > Subject: 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 > > 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.
Thanks for making that suggestion. Although RFC5512 (i.e., draft-ietf-softwire-encaps-safi) and RFC5566 (i.e., draft-ietf-softwire-encaps-ipsec) have been originated from Softwire WG and the current Softwire WG charter (https://tools.ietf.org/wg/softwire/charters) still state that "BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc)", your above suggestion, together with Softwire co-chairs' claim of last Friday that the softwire WG is going to shut down and therefore it would not be a right place to pursue this draft anymore, seem to be a joint statement that any future work related to BGP Encapsulation SAFI should be discussed in the BESS WG, rather than the Softwire WG. Thanks again for clarifying the confusion. > 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#tun > nel-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. IMHO, it depends on whether the tunnel type of the Tunnel Encapsulation TLV as specified in RFC5512 should be interpreted as UDP or MPLS-in-UDP. See the following text quoted 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. 4.4. Tunnel Type Selection A BGP speaker may include multiple tunnel TLVs in the tunnel attribute. The receiving speaker MAY have local policies defined to choose different tunnel types for different sets/types of payload prefixes received from the same BGP speaker. For instance, if a BGP speaker includes both L2TPv3 and GRE tunnel types in the tunnel attribute and it also advertises IPv4 and IPv6 prefixes, the ingress router may have local policy defined to choose L2TPv3 for IPv4 prefixes (provided the protocol type received in the tunnel attribute matches) and GRE for IPv6 prefixes. *************** To keep it in accordance with the usage of the tunnel type as specified in RFC5512, I believe the tunnel type of the Tunnel Encapsulation TLV should be interpreted as UDP, rather than MPLS-in-UDP. That's to say, what type of payload will be carried over the UDP tunnel cloud be explicitly indicated by the protocol type sub-TLV. Best regards, Xiaohu > 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.htm > > > > > > l 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-0 > > > > > > > > 4#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-0 > > > > > > > > 3) 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-paramete > > > > > > > > > > > > > >> rs > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> 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 _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
