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
Xuxiaohu <xuxiaohu@huawei.com> Mon, 02 March 2015 10:07 UTC
Return-Path: <xuxiaohu@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8204A1A7013 for <bess@ietfa.amsl.com>; Mon, 2 Mar 2015 02:07:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npZBM9mbgd5d for <bess@ietfa.amsl.com>; Mon, 2 Mar 2015 02:07:16 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5D01A700D for <bess@ietf.org>; Mon, 2 Mar 2015 02:07:15 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTE11527; Mon, 02 Mar 2015 10:07:14 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Mar 2015 10:07:12 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 2 Mar 2015 18:07:00 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Xuxiaohu <xuxiaohu@huawei.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [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
Thread-Index: AQHQSLr3DiuxdRaR30WUQ5uVlB6ZeJzw6wsggBgiBbA=
Date: Mon, 02 Mar 2015 10:07:00 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830EF91@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083064D3@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083066B6@NKGEML512-MBS.china.huawei.com> <00d801d048ba$e4eb09b0$aec11d10$@olddog.co.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/Qhs85AY12IFSyWbMDWYf1Wfiefo>
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
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2015 10:07:21 -0000
Besides the reasons as mentioned below, since the BGP Encapsulation SAFI for UDP or MPLS-in-UDP is not only applicable to BGP/MPLS-based L2VPN (including VPLS and EVPN) and BGP/MPLS-based L3VPN, but also be applicable to other use cases (e.g., incremental deployment of BGP-based Segment Routing), it seems better to specify it in a separate doc rather than in the end-system-l3vpn draft (http://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/) which is dedicated for how to use XMPP as a replacement of the BGP-L3VPN signaling, IMHO. Best regards, Xiaohu > -----Original Message----- > From: Xuxiaohu > Sent: Sunday, February 15, 2015 11:31 AM > To: 'adrian@olddog.co.uk'; bess@ietf.org > 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 > > Hi Adrian, > > > -----Original Message----- > > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Sunday, February 15, 2015 9:01 AM > > To: bess@ietf.org > > 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#tu > > n > > 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:bess-bounces@ietf.org] On Behalf Of Xuxiaohu > > > Sent: 13 February 2015 06:10 > > > To: Xuxiaohu; bess@ietf.org; bess-chairs@tools.ietf.org > > > Cc: draft-xu-bess-encaps-udp@tools.ietf.org; > > > softwire-chairs@tools.ietf.org > > > 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; bess@ietf.org > > > > 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:bess-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > > Sent: Friday, February 13, 2015 9:21 AM > > > > > To: bess@ietf.org > > > > > 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: 'adrian@olddog.co.uk'; 'Black, David'; > > > > > > rcallon@juniper.net; > > > > > > draft-ietf-l3vpn-end-system@tools.ietf.org; > > > > > > bess-chairs@tools.ietf.org; softwire-chairs@tools.ietf.org > > > > > > Cc: 'Alvaro Retana'; akatlas@gmail.com; '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:adrian@olddog.co.uk] > > > > > > > Sent: Thursday, February 12, 2015 10:50 PM > > > > > > > To: Xuxiaohu; 'Black, David'; rcallon@juniper.net; > > > > > > > draft-ietf-l3vpn-end-system@tools.ietf.org; > > > > > > > bess-chairs@tools.ietf.org; softwire-chairs@tools.ietf.org > > > > > > > Cc: 'Alvaro Retana'; akatlas@gmail.com; '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.h > > > > > > > tm 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:xuxiaohu@huawei.com] > > > > > > > > Sent: 12 February 2015 05:56 > > > > > > > > To: Xuxiaohu; Black, David; adrian@olddog.co.uk; > > > > > > > > rcallon@juniper.net; > > > > > > > > draft-ietf- l3vpn-end-system@tools.ietf.org; > > > > > > > > bess-chairs@tools.ietf.org; softwire- > > > > > > > > chairs@tools.ietf.org > > > > > > > > Cc: Alvaro Retana; akatlas@gmail.com; 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'; adrian@olddog.co.uk; > > > > > > > > > rcallon@juniper.net; 'draft-ietf-l3vpn-end-system@tools.ietf.org' > > > > > > > > > Cc: Alvaro Retana; akatlas@gmail.com; '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#pag > > > > > > > > > e- > > > > > > > > > 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-ud > > > > > > > > > p- > > > > > > > > > 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:david.black@emc.com] > > > > > > > > > > Sent: Wednesday, February 11, 2015 9:58 PM > > > > > > > > > > To: adrian@olddog.co.uk; Xuxiaohu; rcallon@juniper.net > > > > > > > > > > Cc: Alvaro Retana; akatlas@gmail.com; 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:adrian@olddog.co.uk] > > > > > > > > > > > Sent: Wednesday, February 11, 2015 4:53 AM > > > > > > > > > > > To: Black, David; 'Xuxiaohu'; rcallon@juniper.net > > > > > > > > > > > Cc: Alvaro Retana; akatlas@gmail.com > > > > > > > > > > > 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:iana-issues@iana.org] > > > > > > > > > > > > Sent: 09 December 2014 17:40 > > > > > > > > > > > > Cc: thomas.morin@orange.com; adrian@olddog.co.uk; > > > > > > > > > > > > bess@ietf.org; > > > > > > > > > > > > draft-ietf- l3vpn-end-system.all@tools.ietf.org > > > > > > > > > > > > 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, adrian@olddog.co.uk 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: > > > > > > > > > > > > > > >> thomas.morin@orange.com > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> 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-parame > > > > > > > > > > > > > > >> te > > > > > > > > > > > > > > >> 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 > > > > > BESS@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/bess > > > > > > _______________________________________________ > > > BESS mailing list > > > BESS@ietf.org > > > https://www.ietf.org/mailman/listinfo/bess > > > > _______________________________________________ > > BESS mailing list > > BESS@ietf.org > > https://www.ietf.org/mailman/listinfo/bess
- [bess] Why transform draft-xu-softwire-encaps-udp… Xuxiaohu
- Re: [bess] Why transform draft-xu-softwire-encaps… Xuxiaohu
- [bess] Request for WG adoption of draft-xu-bess-e… Xuxiaohu
- Re: [bess] Request for WG adoption of draft-xu-be… Adrian Farrel
- Re: [bess] Request for WG adoption of draft-xu-be… Xuxiaohu
- Re: [bess] Request for WG adoption of draft-xu-be… Xuxiaohu
- Re: [bess] Why transform draft-xu-softwire-encaps… Susan Hares
- Re: [bess] Request for WG adoption of draft-xu-be… Susan Hares
- Re: [bess] Request for WG adoption of draft-xu-be… Xuxiaohu
- Re: [bess] Request for WG adoption of draft-xu-be… Adrian Farrel
- Re: [bess] Request for WG adoption of draft-xu-be… Xuxiaohu