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

[Xuxiaohu <[e-mail]>]

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.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:[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-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:[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-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
> > > > > >
> >