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

["Susan Hares" <[e-mail]>]

Adrian:

IDR also has a next-hop encapsulation draft pending adoption.   May I
suggest that perhaps the BESS/IDR chairs should collaborate on the tunnel
drafts? 

Sue 

-----Original Message-----
From: BESS [mailto:[e-mail]] On Behalf Of Adrian Farrel
Sent: Saturday, February 14, 2015 8:01 PM
To: [e-mail]
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.

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-t
ypes

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:[e-mail]] On Behalf Of Xuxiaohu
> Sent: 13 February 2015 06:10
> To: Xuxiaohu; [e-mail]; [e-mail]
> Cc: [e-mail]; 
> [e-mail]
> 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; [e-mail]
> > Cc: Softwires WG
> > Subject: RE: [bess] Why transform draft-xu-softwire-encaps-udp to 
> > draft-xu-bess-encaps-udp
> >
> > Hi all,
> >
> > I noticed the following text from RFC 5512
(draft-ietf-softwire-encaps-safi):
> >
> > ****************
> > 4.2.  Protocol Type Sub-TLV
> >
> >    The protocol type sub-TLV MAY be encoded to indicate the type of the
> >    payload packets that will be encapsulated with the tunnel parameters
> >    that are being signaled in the TLV.  The value field of the sub-TLV
> >    contains a 2-octet protocol type that is one of the types defined in
> >    [IANA-AF] as ETHER TYPEs.
> >
> >    For example, if we want to use three L2TPv3 sessions, one carrying
> >    IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
> >    packets, the egress router will include three TLVs of L2TPv3
> >    encapsulation type, each specifying a different Session ID and a
> >    different payload type.  The protocol type sub-TLV for these will be
> >    IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and
> >    MPLS (protocol type = 0x8847), respectively.
> > ***************
> >
> > It seems that RFC5512 is not only talking about IP-in-GRE, but also
MPLS-in-GRE.
> >
> > I also noticed an expired IDR WG doc (see
> > https://tools.ietf.org/html/draft-ietf-idr-encaps-safi-00) which was 
> > a predecessor of draft-ietf-softwire-encaps-safi. Besides, RFC5566
> > (draft-ietf-softwire-encaps-ipsec) is also originated from the Softwire
WG.
> Does
> > it mean which WG should be responsible for the BGP Tunnel 
> > Encapsulation Attribute related work had ever been discussed and 
> > finally determined that
the
> > Softwire WG is the right place for it?
> >
> > Best regards,
> > Xiaohu
> >
> >
> > > -----Original Message-----
> > > From: BESS [mailto:[e-mail]] On Behalf Of Xuxiaohu
> > > Sent: Friday, February 13, 2015 9:21 AM
> > > To: [e-mail]
> > > Cc: Softwires WG
> > > Subject: [bess] Why transform draft-xu-softwire-encaps-udp to 
> > > draft-xu-bess-encaps-udp
> > >
> > > Hi all,
> > >
> > > According to the suggestion from Adrian as a Routing co-AD, 
> > > draft-xu-softwire-encaps-udp
> > > (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp) which 
> > > was posted to the Softwire WG is now posted to the BESS WG.
> > >
> > > Any comments and suggestions are welcome.
> > >
> > > Best regards,
> > > Xiaohu
> > >
> > > > -----Original Message-----
> > > > From: Xuxiaohu
> > > > Sent: Friday, February 13, 2015 8:45 AM
> > > > To: '[e-mail]'; 'Black, David'; [e-mail]; 
> > > > [e-mail];
> > > > [e-mail]; [e-mail]
> > > > Cc: 'Alvaro Retana'; [e-mail]; 'Loa Andersson'
> > > > Subject: RE: draft-ietf-l3vpn-end-system and 
> > > > draft-ietf-mpls-in-udp
> > > >
> > > > Hi Adrian,
> > > >
> > > > Thanks a lot for your response. Although RFC5512 (i.e.,
> > > > draft-ietf-softwire-encaps-safi) and RFC5566 (i.e.,
> > > > draft-ietf-softwire-encaps-ipsec) which specify the BGP Tunnel 
> > > > Encapsulation Attribute Tunnel Types for GRE, L2TPv3 and IPsec 
> > > > respectively are all originated from Softwire, and further the 
> > > > Softwire WG co-chairs didn't state that 
> > > > draft-xu-softwire-encaps-udp doesn't belong to their WG, if the 
> > > > BESS and Softwire WG co-chairs could reach an agreement that any 
> > > > future work related to BGP Tunnel Encapsulation Attribute should 
> > > > be done in the BESS WG, it looks fine to me. I would submit the 
> > > > same draft to the BESS WG as
> > > draft-xu-bess-encaps-udp.
> > > >
> > > > Best regards,
> > > > Xiaohu
> > > >
> > > > > -----Original Message-----
> > > > > From: Adrian Farrel [mailto:[e-mail]]
> > > > > Sent: Thursday, February 12, 2015 10:50 PM
> > > > > To: Xuxiaohu; 'Black, David'; [e-mail]; 
> > > > > [e-mail];
> > > > > [e-mail]; [e-mail]
> > > > > Cc: 'Alvaro Retana'; [e-mail]; 'Loa Andersson'
> > > > > Subject: RE: draft-ietf-l3vpn-end-system and 
> > > > > draft-ietf-mpls-in-udp
> > > > >
> > > > > Hello all,
> > > > >
> > > > > 1. Why softwire? That is strictly IP-in-IP with a particular 
> > > > > intention of 4-over-6 and 6-over-4. Why would MPLS-in-UDP fall 
> > > > > into their
> > > charter?
> > > > > You say "all the specifications for the BGP signaling for GRE, 
> > > > > IPsec and etc were all defined in separate drafts belonging to 
> > > > > the Softwire WG" but I see no evidence of this. The only 
> > > > > vaguely related draft I can see is draft-xu-softwire-ip-in-udp 
> > > > > which is a specific IP-over-UDP-over-IP mechanism about which 
> > > > > I will reserve judgement except to say that I that softwire 
> > > > > really needs yet another transition mechanism and that I 
> > > > > believe IP-in-IP can be hashed by existing ECMP
> > > > hardware.
> > > > >
> > > > > You also referenced draft-xu-softwire-encaps-udp but I believe 
> > > > > this document expired over 12 months ago. I would not say that 
> > > > > it was the most substantive or technical document I have ever 
> > > > > read
> > > > > :-)
> > > > >
> > > > > I have not removed the chairs from this thread, but I really 
> > > > > hate spamming people's in-boxes.
> > > > >
> > > > > 2. While Xiaohu has correctly pointed at the current version 
> > > > > of the I-D, it might be better to look at the status in the 
> > > > > Datatracker via 
> > > > > http://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/
> > > > > - You'll see that the status is Waiting for AD 
> > > > > Go-Ahead::Revised I-D Needed which means it has completed IETF 
> > > > > last call and is waiting for a
> > > > revision.
> > > > >
> > > > > 3. If you are following the BESS mailing list, you'll see that 
> > > > > there is text agreed with IANA to fix the "empty" IANA 
> > > > > considerations
> > section.
> > > > > http://www.ietf.org/mail-archive/web/bess/current/msg00233.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:[e-mail]]
> > > > > > Sent: 12 February 2015 05:56
> > > > > > To: Xuxiaohu; Black, David; [e-mail]; 
> > > > > > [e-mail];
> > > > > > draft-ietf- [e-mail]; 
> > > > > > [e-mail]; softwire- [e-mail]
> > > > > > Cc: Alvaro Retana; [e-mail]; Loa Andersson
> > > > > > Subject: RE: draft-ietf-l3vpn-end-system and 
> > > > > > draft-ietf-mpls-in-udp
> > > > > >
> > > > > > By the way, I think it would be better to allow the BESS and 
> > > > > > Softwire WG co-chairs to be involved.
> > > > > >
> > > > > > Best regards,
> > > > > > Xiaohu
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Xuxiaohu
> > > > > > > Sent: Thursday, February 12, 2015 9:47 AM
> > > > > > > To: 'Black, David'; [e-mail]; 
> > > > > > > [e-mail];
'[e-mail]'
> > > > > > > Cc: Alvaro Retana; [e-mail]; 'Loa Andersson'
> > > > > > > Subject: RE: draft-ietf-l3vpn-end-system and 
> > > > > > > draft-ietf-mpls-in-udp
> > > > > > >
> > > > > > > (cced to the authors of the end-system draft)
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I thinks there must be some avoidable mistaken IANA action
request.
> > > > > > > The IANA Considerations of the latest version of the 
> > > > > > > end-system draft 
> > > > > > > (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-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:[e-mail]]
> > > > > > > > Sent: Wednesday, February 11, 2015 9:58 PM
> > > > > > > > To: [e-mail]; Xuxiaohu; [e-mail]
> > > > > > > > Cc: Alvaro Retana; [e-mail]; Black, David
> > > > > > > > Subject: RE: draft-ietf-l3vpn-end-system and 
> > > > > > > > draft-ietf-mpls-in-udp
> > > > > > > >
> > > > > > > > Adrian,
> > > > > > > >
> > > > > > > > Ok, that's roughly what I expected - between IANA and 
> > > > > > > > the RFC Editor, the l3vpn-end-system draft will record 
> > > > > > > > IANA's
actions
> > here.
> > > > > > > >
> > > > > > > > I had included you as the (ir)responsible AD for the 
> > > > > > > > l3vpn-end-system draft, and indeed what is transpiring 
> > > > > > > > is a version of "ADs can make many
> > > > > > > things happen."
> > > > > > > >
> > > > > > > > The good news is that we don't need another draft to 
> > > > > > > > allocate that BGP tunnel type code point, which was 
> > > > > > > > where this whole thread started, so chalk this up as a 
> > > > > > > > small victory in the never-ending battle to reduce IESG
> > > > > > > workload ;-).
> > > > > > > >
> > > > > > > > Alvaro - welcome, and congratulations on your new role!
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > --David
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Adrian Farrel [mailto:[e-mail]]
> > > > > > > > > Sent: Wednesday, February 11, 2015 4:53 AM
> > > > > > > > > To: Black, David; 'Xuxiaohu'; [e-mail]
> > > > > > > > > Cc: Alvaro Retana; [e-mail]
> > > > > > > > > Subject: draft-ietf-l3vpn-end-system and 
> > > > > > > > > draft-ietf-mpls-in-udp
> > > > > > > > >
> > > > > > > > > Hi and sorry,
> > > > > > > > >
> > > > > > > > > I should have looked more deeply *before* sending my 
> > > > > > > > > previous
> > > email.
> > > > > > > > >
> > > > > > > > > Here is the resolution to IANA's issue with 
> > > > > > > > > draft-ietf-l3vpn-end-system that I proposed and they
accepted.
> > > > > > > > >
> > > > > > > > > We're just waiting for the authors of 
> > > > > > > > > draft-ietf-l3vpn-end-system to do something.
> > > > > > > > >
> > > > > > > > > A
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Pearl Liang via RT 
> > > > > > > > > > [mailto:[e-mail]]
> > > > > > > > > > Sent: 09 December 2014 17:40
> > > > > > > > > > Cc: [e-mail]; [e-mail]; 
> > > > > > > > > > [e-mail];
> > > > > > > > > > draft-ietf- [e-mail]
> > > > > > > > > > Subject: [IANA #798045] IANA's comments on 
> > > > > > > > > > draft-ietf-l3vpn-end-system
> > > > > > > > > >
> > > > > > > > > > Hi Adrian,
> > > > > > > > > >
> > > > > > > > > > This makes it clear whether or not that assignment 
> > > > > > > > > > needs to be updated when this draft is approved for 
> > > > > > > > > > publication as
RFC:
> > > > > > > > > >
> > > > > > > > > > [[[
> > > > > > > > > > I think that might be valuable. So the IANA section 
> > > > > > > > > > should
read...
> > > > > > > > > >
> > > > > > > > > >    IANA has previously made an allocation from the 
> > > > > > > > > > "BGP Tunnel
> > > > > > > > Encapsulation
> > > > > > > > > >    Attribute Tunnel Types" registry that reads:
> > > > > > > > > >
> > > > > > > > > >    Value  | Name                      | Reference
> > > > > > > > > >
--------+---------------------------+-------------------------------
> > > > > > > > > >        13  | MPLS in UDP Encapsulation | 
> > > > > > > > > > [draft-ietf-l3vpn-end-system]
> > > > > > > > > >
> > > > > > > > > >    IANA is requested to change the reference to 
> > > > > > > > > > point to the RFC
> > > > > number
> > > > > > > > > >    of this document when it is published.
> > > > > > > > > >
> > > > > > > > > > ]]]
> > > > > > > > > >
> > > > > > > > > > The current text  "This document has no IANA actions."
> > > > > > > > > > provides no instructions and incorrectly tell people 
> > > > > > > > > > there is no actions
> > > > > requested.
> > > > > > > > > >
> > > > > > > > > > Thanks
> > > > > > > > > > ~pl
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue Dec 09 13:20:57 2014, [e-mail] wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > Replying to myself and keeping the same IANA 
> > > > > > > > > > > tracking
> number.
> > > > > > > > > > >
> > > > > > > > > > > > > IESG/Authors/WG Chairs:
> > > > > > > > > > > > >
> > > > > > > > > > > > > IANA has reviewed draft-ietf-l3vpn-end-system-04.
> > > > > > > > > > > > > Authors should
> > > > > > > > > > > review
> > > > > > > > > > > > > the comments and/or questions below.  Please 
> > > > > > > > > > > > > report any
> > > > > > > > > > > inaccuracies and
> > > > > > > > > > > > > respond to any questions as soon as possible.
> > > > > > > > > > > > >
> > > > > > > > > > > > > IANA's reviewer has the following
comments/questions:
> > > > > > > > > > > > >
> > > > > > > > > > > > > IANA has a question about the IANA 
> > > > > > > > > > > > > Considerations section of this
> > > > > > > > > > > document.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Previously, an early assignment has been made 
> > > > > > > > > > > > > to support this
> > > > > > > > > > > draft. The
> > > > > > > > > > > > > original request for an assignment is below:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> <begin request=""> Contact Name:
> > > > > > > > > > > > >> Thomas Morin
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Contact Email:
> > > > > > > > > > > > >> [e-mail]
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Type of Assignment:
> > > > > > > > > > > > >> Assignement of a BGP parameter in a FCFS
registry.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Registry:
> > > > > > > > > > > > >> BGP Tunnel Encapsulation Attribute Tunnel 
> > > > > > > > > > > > >> Types
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> See:
> > > > > > > > > > > > >> https://www.iana.org/assignments/bgp-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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/bess
> 
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess

_______________________________________________
BESS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bess