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

["Adrian Farrel" <[e-mail]>]

OK,

So you want an I-D that describes how to use the code point to achieve a variety
of things. That is potentially useful, but I haven't read that text in your I-D.

But please understand that the code point is already allocated (and I shouldn't
be surprised to hear it is coded and deployed). So it is way too late to say
that the wrong document asked for the code point.

Adrian

> -----Original Message-----
> From: Xuxiaohu [mailto:[e-mail]]
> Sent: 02 March 2015 10:07
> To: Xuxiaohu; [e-mail]; [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
> 
> 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: '[e-mail]'; [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
> >
> > Hi Adrian,
> >
> > > -----Original Message-----
> > > From: BESS [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > > Sent: Sunday, February 15, 2015 9:01 AM
> > > 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.
> >
> > 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:[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.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:[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]; 'draft-ietf-l3vpn-end-
> [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#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:[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-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
> > > > > > [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