Re: [OSPF] I-D Action: draft-ietf-ospf-encapsulation-cap-05.txt

Speaking as document shepherd:

This version resolves Alia’s AD comments. The is now using 2-octet Sub-TLV
type/length consistent with RFC 7770. For tunnel types, the existing RFC
5512 registry is referenced. For the Tunnel Encapsulation Attributes, we
elected to take the most straightforward approach and have a separate OSPF
registry. This will avoid the fact that BGP advertises at least one of
these attributes in communities (e.g., color) and the fact that IS-IS has
a different one-octet type/length vs OSPF’s 2-octet type/length.

Speaking as WG Co-Chair:

This also begins a 2-week last call on these changes (ends Tues, August
1st) at 12:00 AM UTC. This shouldn’t cause much delay (assuming consensus)
as Alia is backed up right now with this week’s IETF and a queue of other
documents. 

Thanks,
Acee

On 7/17/17, 3:50 AM, "bruno.decraene@orange.com"
<bruno.decraene@orange.com> wrote:

>Hi Alia, Acee, all
>
>draft-ietf-ospf-encapsulation-cap-06 has just been uploaded to address
>the comments received.
>Draft: https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-06
>Diff: 
>https://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-06.t
>xt
>
>Please see inline [Authors] more details about issues resolution
>
>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
>>(acee)
> > Sent: Wednesday, July 05, 2017 7:59 PM
> > To: Alia Atlas
> > Cc: ospf@ietf.org
> > Subject: Re: [OSPF] I-D Action:
>draft-ietf-ospf-encapsulation-cap-05.txt
> > 
> > Hi Alia,
> > 
> > So the issues we are still discussing are:
> > 
> >       1. Common IGP Tunnel Type/Tunnel Attribute IANA Registry or
>simply
> > reference the BGP registries created by RFC 5512.
>
>[Authors] There are 2 registries:
>a) Tunnel Encapsulation Type: registry shared with BGP  (since draft-05)
>Tunnel types are shared with the BGP  extension [RFC5512] and hence are
>defined in the existing IANA registry  "BGP Tunnel Encapsulation
>Attribute Tunnel Types".
>https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-05#section-4
>
>b) Tunnel Encapsulation Attribute Sub-TLVs: registry dedicated to OSPF
>(changed in draft-06)
>- Difficult to share with IS-IS as IS-IS has TLV size restrictions which
>do not match BGP and OSPF. Due to this restriction future sub-TLV may be
>encoded in a more compact way, possibly with less information.
>- Difficult to share with BGP as BGP attach the attribute to various type
>of BGP routes hence needs to handle labelled/unlabeled routes,
>underlay/overlay routes... The color sub-TLV already has a different
>syntax. (yet the same sub-TLV code point could have been used.)
>
> >       2. 1-octet or 2-octet type/length in Tunnel Encapsulation
>Attribute
> > Sub-TLVs. I’d vote for 2-octet for RFC 7770 consistency even though the
> > BGP registry code point is limited to 255 types.
>
>[Authors] draft-06 use 2 octets to encode the type, and 2 octets to
>encode the length, as typical for OSPF.
>
> >       3. Addition of the RFC 5640 ECMP block suggested by Carlos
>
>[Authors] Done.
>
>Thanks
>--Authors
>
> > Pignataro.
> > 
> > Thanks,
> > Acee
> > 
> > 
> > On 7/3/17, 10:52 AM, "OSPF on behalf of internet-drafts@ietf.org"
> > <ospf-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:
> > 
> > >
> > >A New Internet-Draft is available from the on-line Internet-Drafts
> > >directories.
> > >This draft is a work item of the Open Shortest Path First IGP of the
>IETF.
> > >
> > >        Title           : Advertising Tunneling Capability in OSPF
> > >        Authors         : Xiaohu Xu
> > >                          Bruno Decraene
> > >                          Robert Raszuk
> > >                          Luis M. Contreras
> > >                          Luay Jalil
> > >	Filename        : draft-ietf-ospf-encapsulation-cap-05.txt
> > >	Pages           : 10
> > >	Date            : 2017-07-03
> > >
> > >Abstract:
> > >   Networks use tunnels for a variety of reasons.  A large variety of
> > >   tunnel types are defined and the ingress needs to select a type of
> > >   tunnel which is supported by the egress and itself.  This document
> > >   defines how to advertise egress tunnel capabilities in OSPF Router
> > >   Information Link State Advertisement (LSAs).
> > >
> > >
> > >
> > >The IETF datatracker status page for this draft is:
> > >https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/
> > >
> > >There are also htmlized versions available at:
> > >https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-05
> > 
>>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-0
>>5
> > >
> > >A diff from the previous version is available at:
> > >https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-05
> > >
> > >
> > >Please note that it may take a couple of minutes from the time of
> > >submission
> > >until the htmlized version and diff are available at tools.ietf.org.
> > >
> > >Internet-Drafts are also available by anonymous FTP at:
> > >ftp://ftp.ietf.org/internet-drafts/
> > >
> > >_______________________________________________
> > >OSPF mailing list
> > >OSPF@ietf.org
> > >https://www.ietf.org/mailman/listinfo/ospf
> > 
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
>
>__________________________________________________________________________
>_______________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.
>