Subject: [Softwires] Why transform draft-xu-softwire-encaps-udp to draft-xu-bess-encaps-udp

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Feb 2015 01:21:02 +0000

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-masked]'; 'Black, David'; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Cc: 'Alvaro Retana'; [email-masked]; '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-masked]]
> > Sent: Thursday, February 12, 2015 10:50 PM
> > To: Xuxiaohu; 'Black, David'; [email-masked];
> > [email-masked];
> > [email-masked]; [email-masked]
> > Cc: 'Alvaro Retana'; [email-masked]; '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-masked]]
> > > Sent: 12 February 2015 05:56
> > > To: Xuxiaohu; Black, David; [email-masked];
> > > [email-masked];
> > > draft-ietf- [email-masked];
> > > [email-masked]; softwire- [email-masked]
> > > Cc: Alvaro Retana; [email-masked]; 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-masked]; [email-masked];
> > > > [email-masked]'
> > > > Cc: Alvaro Retana; [email-masked]; '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-masked]]
> > > > > Sent: Wednesday, February 11, 2015 9:58 PM
> > > > > To: [email-masked]; Xuxiaohu; [email-masked]
> > > > > Cc: Alvaro Retana; [email-masked]; 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-masked]]
> > > > > > Sent: Wednesday, February 11, 2015 4:53 AM
> > > > > > To: Black, David; 'Xuxiaohu'; [email-masked]
> > > > > > Cc: Alvaro Retana; [email-masked]
> > > > > > 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-masked]]
> > > > > > > Sent: 09 December 2014 17:40
> > > > > > > Cc: [email-masked]; [email-masked];
> > > > > > > [email-masked];
> > > > > > > draft-ietf- [email-masked]
> > > > > > > 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-masked] 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-masked]
> > > > > > > > > >>
> > > > > > > > > >> 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
> > > > > >
> >

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Feb 2015 04:12:32 +0000

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

> From: BESS [mailto:[email-masked]] On Behalf Of Xuxiaohu
> Sent: Friday, February 13, 2015 9:21 AM
> To: [email-masked]
> 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.
> 
> > 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
> > > 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?
> > > 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
> > > 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.
> > >
> > > 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.
> > >
> > >
> > > 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.
> > > > > (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
> > > > > (https://tools.ietf.org/html/draft-xu-mpls-in-udp-00#page-4)
> > > > > which was published April 28, 2012. However, According to the WG
> > > > > 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
> > > > > 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
> > > > > > > > This makes it clear whether or not that assignment needs
> > > > > > > > to be updated when this draft is approved for publication as RFC:
> > > > > > > >
> > > > > > > > [[[
> > > > > > > > the RFC
> > > > > > > > > > >> 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 .
> > > > > > > > > > >>
> > > > > > > > > > > IANA Question --> The IANA Considerations section
> > > > > > > > > > > said "This
> > > > > > > > > document has
> > > > > > > > > should ask for the registry to be updated to point to
> > > > > > > > > the consequent RFC instead of the I-D.
> > > > > > > > >
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 15 Feb 2015 09:15:31 -0500

Xiaohu:

That the draft came through softwire is self-evident.  That it was
appropriate to come to Softwire instead of IDR: (see
https://tools.ietf.org/html/draft-ietf-idr-encaps-safi-00),  this means the
IDR chairs dropped the ball. 

I'm working hard to catch all the BGP related reviews, and I believe the
routing directorate is also looking at these cross-review issues.  

Sue Hares

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, February 12, 2015 11:13 PM
To: Xuxiaohu; [email-masked]
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):

****************

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

> (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp) which was 
> posted to the Softwire WG is now posted to the BESS WG.
> 
> > > 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 
> > > :-)
> > >
> > > 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 
> > > - 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.
> > > 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 
> > > A. Assign a BGP Tunnel Encapsulation Attribute Tunnel Type. This 
> > > has already been done. No amount of effort to change documents or 
> > > 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.
> > > > > The IANA Considerations of the latest version of the 
> > > > > end-system draft 
> > > > > (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-04#pa
> > > > > ge
> > > > > -2
> > > > > 1)
> > > > > which
> > > > was
> > > > > published on October 2, 2014 clearly states that " This 
> > > > > document has no IANA actions." Furthermore, the -03 version
> > > > > 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
> > > > > 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.
> > > > >
> > > > > 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
> > > > >
> > > > > > Ok, that's roughly what I expected - between IANA and the 
> > > > > > RFC Editor, the l3vpn-end-system draft will record IANA's
actions here.
> > > > > > 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 ;-).
> > > > > >
> > > > > > > I should have looked more deeply *before* sending my 
> > > > > > > previous
> email.
> > > > > > >
> > > > > > > > provides no instructions and incorrectly tell people 
> > > > > > > > there is no actions
> > > requested.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > ~pl
> > > > > > > >
> > > > > > > >
> > > > > > > > > > > the comments and/or questions below.  Please 
> > > > > > > > > > > report any
> > > > > > > > > inaccuracies and
> > > > > > > > > > >> <begin request=""> Contact Name:
> > > > > > > > > > >> Thomas Morin
> > > > > > > > > > >>
> > > > > > > > > > >> Contact Email:
> > > > > > > > > > >> [email-masked]
> > > > > > > > > > >>
> > > > > > > > > > >> Type of Assignment:
> > > > > > > > > > > no IANA actions."  and, as a result, the 
> > > > > > > > > > > assignment made through
> > > > > > > > > the request
> > > > > > > > > > > the draft be revised to indicate that the 
> > > > > > > > > > > assignment made based on
> > > > > > > > > the
> > > > > > > > > request
> > > > > > > > > The assignment has been made and is as permanent as 
> > > > > > > > > any FCFS assignment ever is.
> > > > > > > > >
> > > > > > > > > Yes, but this is a FCFS registry to which 7120 does 
> > > > > > > > > not apply, and nor does "reservation of values".
> > > > > > > > >    IANA has previously made an allocation from the 
> > > > > > > > > "BGP Tunnel Encapsulation
> > > > > > > > >    IANA is requested to change the reference to point 
> > > > > > > > > to the RFC number