Subject: [OSPF] draft-ietf-ospf-encapsulation-cap

From: <[email-masked]>
Date: Mon, 18 Sep 2017 15:53:41 +0000

Hi all,

-07 & -08 have been uploaded following AD, directorates and IESG reviews.

Many changes are editorial.

A significant one is that Names of the TLV have changed:

>From  (-06) :
3. Advertising Encapsulation Capability . . . . . . . . . . . . 3

To  (-08) :
3. Tunnel Encapsulations TLV . . . . . . . . . . . . . . . . . . 3

4. Tunnel Encapsulation Type . . . . . . . . . . . . . . . . . . 4

4. Tunnel Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 3

5. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 4

5. Tunnel Parameter Sub-TLVs . . . . . . . . . . . . . . . . . . 4

There is an outstanding comment from Joe Touch, asking to change the encoding of the Endpoint sub-TLV:

- currently the distinction between IPv4 and IPv6 is performed by checking the length field, as done by some RFCs and RFC 5512 (defining the original BGP tunnel extension)

- Joe is proposing to add an explicit Address Family field. This would also be aligned with the new BGP draft https://tools.ietf.org/html/draft-rosen-idr-tunnel-encaps-03#section-2.1

Clearly this encoding change would not be backward compatible. A priori, there should not be running code as there is no early IANA allocation of the code points.

- Any opinion regarding encoding preference?

- Would this change be an issue for someone?

Thanks,

Regards,

--Bruno, on behalf of all authors.

> -----Original Message-----

> From: I-D-Announce [mailto:[email-masked]] On Behalf Of internet-

> [email-masked]

> Sent: Monday, September 18, 2017 5:33 PM

> To: [email-masked]

> Cc: [email-masked]

> Subject: I-D Action: draft-ietf-ospf-encapsulation-cap-08.txt

 > 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 WG of the IETF.

 >         Title           : The Tunnel Encapsulations OSPF Router Information

>         Authors         : Xiaohu Xu

>                           Bruno Decraene

>                           Robert Raszuk

>                           Luis M. Contreras

>                           Luay Jalil

>         Filename        : draft-ietf-ospf-encapsulation-cap-08.txt

>         Pages           : 10

>         Date            : 2017-09-18

 > Abstract:

>    Networks use tunnels for a variety of reasons.  A large variety of

>    tunnel types are defined and the tunnel encapsulator router needs to

>    select a type of tunnel which is supported by the tunnel decapsulator

>    router.  This document defines how to advertise, in OSPF Router

>    Information Link State Advertisement (LSAs), the list of tunnel

>    encapsulations supported by the tunnel decapsulator.

 > 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-08

> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-08

 > A diff from the previous version is available at:

> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-08

 > 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/

 > _______________________________________________

> I-D-Announce mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/i-d-announce

> Internet-Draft directories: http://www.ietf.org/shadow.html

> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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.