Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 6 Jun 2016 17:11:57 +0000

Hi Thomas,

I updated and checked-in a new rev of this draft couple of weeks ago to address the comments that came up on this email thread - the main changes were outlined in my previous email. Can you please progress this draft for its LC. If there is any issue preventing the progress of this draft, would you let us know.

Regards,
Ali

From: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 24, 2016 at 12:04 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>, Thomas Morin <[email-masked]<mailto:[email-masked]>>, IDR <[email-masked]<mailto:[email-masked]>>, BESS <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
Resent-From: <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>
Resent-To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, May 24, 2016 at 12:05 AM

Folks,

I have updated and published rev03 of even-overlay draft.
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/

The main changes are:

  1.  section 10.2 - DCI using ASBR
  2.  The setting of Ethernet tag and VNI fields - there were some inconsistencies in different sections. Section 5.1.3 captures the setting of these fields for different type of services in pretty good details. All other sections were cleaned up and now refer to section 5.1.3.

Thomas,
The draft is ready for its long-overdue WG LC considering how long its has been around and its multi-vendor implementation status.

Regards,
Ali

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 7 Jun 2016 10:08:21 +0200

Hi,

We are fine with keeping 5512 as the Normative reference for now.
We would think it wise if the editors can add an Informative reference 
to draft-ietf-idr-tunnel-encaps (with some text indicating that both 
specs provide the required support for the procedures).
The ideal situation would be that tunnel-encaps progresses fast enough 
so that in the last stages before publishing evpn-overlay we can be in a 
situation to make tunnel-encaps the Normative reference. RFC 4897 would 
facilitate that by the way.

If the WG has specific opinions on that matter, they are welcome.

We take good note of the shepherd suggestion. We'll confirm who will 
shepherd the document after WG LC (we'll also call for volunteers during 
WG Last Call).

Reviews are highly welcome anyway, in particular from people
close to the topic or implementations, and ideally from more than one
person, the best time being now or at least before the WG LC ends.

We'll start the WG LC in a couple of days.

Martin & Thomas

Le 24/05/2016 15:39, John E Drake a écrit :
> Hi,
>
> Ali and I decided to keep the normative reference to RFC 5512 rather
> than changing it to Eric’s tunnel encapsulation draft because the
> normative reference pre-dates Eric’s draft and because our draft does
> not use any of the new capabilities introduced in Eric’s draft.
>
> Ali and I would also like to request that Jorge be the document shepherd
> for this draft.
>
> Yours Irrespectively,
>
> John
>
> *From:*Ali Sajassi (sajassi) [mailto:[email-masked]]
> *Sent:* Tuesday, May 24, 2016 3:05 AM
> *To:* John E Drake; EXT - [email-masked]; IDR; BESS;
> [email-masked]; Rabadan, Jorge (Nokia -
> US); [email-masked]
> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs.
> draft-ietf-idr-tunnel-encaps
>
> Folks,
>
>  1. section 10.2 – DCI using ASBR
>  2. The setting of Ethernet tag and VNI fields – there were some
>     inconsistencies in different sections. Section 5.1.3 captures the
>     setting of these fields for different type of services in pretty
>     good details. All other sections were cleaned up and now refer to
>     section 5.1.3.
>
> Thomas,
>
> The draft is ready for its long-overdue WG LC considering how long its
> has been around and its multi-vendor implementation status.
>
> Regards,
>
> Ali
>
>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 7 Jun 2016 16:04:16 +0000

Hi Martin,

We¹ll also add idr-tunnel-encaps a Informative reference. With respect to
Tunnel Encap Extended Community (which is the only part of
idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft itself
references RFC 5512.

During the course of WG LC and RFC editorship of evpn-overlay draft, if we
see that idr-tunnel-encap is progressing fast, then we can drop the
reference to RFC 5512 and make the reference to idr-tunnel-encap
Normative. Otherwise, we¹ll keep both references with RFC 5512 as
Normative and idr-tunnel-encap as Informative.

Regards,
Ali

On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux"
<[email-masked] on behalf of [email-masked]> wrote:

>> than changing it to Eric¹s tunnel encapsulation draft because the
>> normative reference pre-dates Eric¹s draft and because our draft does
>> not use any of the new capabilities introduced in Eric¹s draft.
>>
>>  1. section 10.2  DCI using ASBR
>>  2. The setting of Ethernet tag and VNI fields  there were some

---

From: John E Drake <[email-masked]>
Date: Tue, 7 Jun 2016 17:41:04 +0000

This sounds like a plan.

Yours Irrespectively,

John

> -----Original Message-----
> From: BESS [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)
> Sent: Tuesday, June 07, 2016 12:04 PM
> To: Martin Vigoureux; [email-masked]
> Cc: Ali Sajassi (sajassi)
> Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
> 
> 
> Hi Martin,
> 
> We¹ll also add idr-tunnel-encaps a Informative reference. With respect to Tunnel Encap
> Extended Community (which is the only part of idr-tunnel-encap used by evpn-overlay
> draft), idr-tunel-encap draft itself references RFC 5512.
> 
> During the course of WG LC and RFC editorship of evpn-overlay draft, if we see that idr-
> tunnel-encap is progressing fast, then we can drop the reference to RFC 5512 and make the
> reference to idr-tunnel-encap Normative. Otherwise, we¹ll keep both references with RFC
> 5512 as Normative and idr-tunnel-encap as Informative.
> 
> Regards,
> Ali
> 
> >so that in the last stages before publishing evpn-overlay we can be in
> >a situation to make tunnel-encaps the Normative reference. RFC 4897
> >would facilitate that by the way.
> >
> >shepherd the document after WG LC (we'll also call for volunteers
> >during WG Last Call).
> >
> >Reviews are highly welcome anyway, in particular from people close to
> >the topic or implementations, and ideally from more than one person,
> >the best time being now or at least before the WG LC ends.
> >
> >> Ali and I would also like to request that Jorge be the document
> >> shepherd for this draft.
> >>
> >> Yours Irrespectively,
> >>
> >> John
> >>
> >> The draft is ready for its long-overdue WG LC considering how long
> >> its has been around and its multi-vendor implementation status.
> >>
> >> Regards,
> >>
> >> Ali
> >>
> >>
> >>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 8 Jun 2016 08:19:18 +0200

Thank you Ali

---

From: Thomas Morin <[email-masked]>
Date: Mon, 13 Jun 2016 17:49:11 +0200

Hi Ali,

The changes in -04 look good.

I would have one suggestion: say explicitly that the "use the label as 
the VNI" behavior is  the same as what the tunnel encap says.

This could be done by adding something like the following to section  
5.1.3 :

Note that the procedure defined here to use the MPLS Label field to 
carry the VNI in the presence
    of a Tunnel Encapsulation Extended Community specifying the use of a 
VNI, is
    aligned with the procedures described in [tunnel-encap] (Section 
"Use of Virtual Network
    Identifiers and Embedded Labels when Imposing a Tunnel Encapsulation 
" for "Labeled Address Families").

Best,

-Thomas

Le 07/06/2016 à 18:04, Ali Sajassi (sajassi) a écrit :
>>> *To:* John E Drake; EXT [email-masked]; IDR; BESS;
>>> US);[email-masked]

---

From: John E Drake <[email-masked]>
Date: Mon, 13 Jun 2016 19:25:58 +0000

Thomas,

I completely agree.  This is an excellent way to provide linkage with the tunnel encaps draft. 

Yours Irrespectively,

John

> From: BESS [mailto:[email-masked]] On Behalf Of Thomas Morin
> Sent: Monday, June 13, 2016 11:49 AM
> To: [email-masked]
> I would have one suggestion: say explicitly that the "use the label as the VNI" behavior is
> the same as what the tunnel encap says.
> 
> Note that the procedure defined here to use the MPLS Label field to carry the VNI in the
> presence
>     of a Tunnel Encapsulation Extended Community specifying the use of a VNI, is
>     aligned with the procedures described in [tunnel-encap] (Section "Use of Virtual Network
>     Identifiers and Embedded Labels when Imposing a Tunnel Encapsulation " for "Labeled
> Address Families").
> 
> Best,
> 
> -Thomas
> 
> 
> 
> > We¹ll also add idr-tunnel-encaps a Informative reference. With respect
> > to Tunnel Encap Extended Community (which is the only part of
> > idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft
> > itself references RFC 5512.
> >
> > During the course of WG LC and RFC editorship of evpn-overlay draft,
> > if we see that idr-tunnel-encap is progressing fast, then we can drop
> > the reference to RFC 5512 and make the reference to idr-tunnel-encap
> >> We would think it wise if the editors can add an Informative
> >> reference to draft-ietf-idr-tunnel-encaps (with some text indicating
> >> that both specs provide the required support for the procedures).
> >> The ideal situation would be that tunnel-encaps progresses fast
> >> enough so that in the last stages before publishing evpn-overlay we
> >> can be in a situation to make tunnel-encaps the Normative reference.
> >> RFC 4897 would facilitate that by the way.
> >>
> >>> normative reference pre-dates Eric¹s draft and because our draft
> >>> does not use any of the new capabilities introduced in Eric¹s draft.
> >>>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 14 Jun 2016 05:32:58 +0000

Hi Thomas,

Referencing the section 8 of idr-tunnel-encap draft is too wide a scope
IMHO and maybe confusing, thus I'd like to narrow it down. I went over the
both sections 3.5 and 8 of the idr-tunnel-encap draft and with respect to
your comment, I’d like to narrow it to only section 8.2.2.2. ("When a
Valid VNI has not been Signaled”) with regard to its applicability to
evpn-overlay draft - to be more precise is the 2nd bullet of section
8.2.2.2. So, I’d like to change your suggested text to:

"Note that the procedure defined here to use the MPLS Label field to carry
the VNI in the presence of a Tunnel Encapsulation Extended Community
specifying the use of a VNI, is aligned with the procedures described in
section 8.2.2.2 of [tunnel-encap] (“When a Valid VNI has not been
Signaled”).

Cheers,
Ali

On 6/13/16, 8:49 AM, "BESS on behalf of Thomas Morin"
<[email-masked] on behalf of [email-masked]> wrote:

>>to
>>>a
>>>during
>>>>shepherd

---

From: <[email-masked]>
Date: Tue, 14 Jun 2016 07:24:45 +0000

Sounds perfect.

Thanks,

-Thomas

---- Ali Sajassi (sajassi) a écrit ----

Hi Thomas,

Cheers,
Ali

>>>> has been around and its multi-vendor implementation status.

_________________________________________________________________________________________________________________________

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.

---

From: Thomas Morin <[email-masked]>
Date: Wed, 15 Jun 2016 14:47:28 +0200

Hi John, Ali,

Through the discussion below it appeared that section 9 and section 
5.1.3 needed adjustments to be brought in sync, and indeed there were 
some changes in last revision.

However, I don't think the cleanup/precision is complete yet:
- section 5.1.3 says "the MPLS label field in the [...] Inclusive 
Multicast Ethernet Tag routes is used to carry the VNI" although the 
"Inclusive Multicast Ethernet Tag Route" has no "MPLS label field"
- (directly related to the above) none of these section talks about 
using the MPLS field of the PMSI Tunnel Attribute as the VNI, although 
the discussion below concluded that it is what implementations actually do
- also, section 9 now says "The Ethernet Tag field of this route is set 
as described in section 5.1.3.", but I find this sentence useless and 
redundant (precisely because 5.1.3 already says it and nothing would 
indicate that section 9 would be exempt of what 5.1.3 says)

Additionally, it occurred to me that "the MPLS field" is not, strictly 
speaking, unambiguous for MAC Advertisement routes, because the route 
actually has two MPLS fields.  The text should just say "MPLS Label1 
field" for the MAC/IP advertisement route.

Best,

-Thomas

2016-05-04, John E Drake:
> Jorge,
>
> We put the VNI value in the MPLS label field of the PMSI attribute for all service types, and we put a value in the Ethernet Tag field following the rules for each service type as described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3).
>
> You're right that we need to clean up section 9.
>
> Yours Irrespectively,
>
> John
>
>> From: Rabadan, Jorge (Nokia - US) [mailto:[email-masked]]
>> Sent: Wednesday, May 04, 2016 3:53 PM
>> To: John E Drake; EXT - [email-masked]; BESS; IDR; draft-ietf-bess-evpn-
>> [email-masked]; Ali Sajassi (sajassi)
>> Hi John,
>> About this:
>> [JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we need
>> to ask everyone whether they used the Ethernet Tag or the PMSI attribute to carry the VNI
>>
>>
>> In case it helps, I’ve seen a few implementations running and they all encode the VNI in the
>> MPLS label field in the PTA. And a couple of them, encode the VNI in the ethernet-tag, in
>> addition to the MPLS label in the PTA. In any case, I think section 9 contradicts section 5.1.3
>> and should be clarified.
>>
>> "5.1.3 Constructing EVPN BGP Routes
>> <snip>
>> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and **Inclusive
>> Multicast Ethernet Tag** routes is used to carry the VNI or VSID."
>>
>> Thanks.
>> Jorge
>>
>>
>>
>>
>>
>> On 5/4/16, 8:34 PM, "EXT John E Drake" <[email-masked]> wrote:
>>
>>> Thomas and Jorge,
>>>
>>> Snipped, comments inline.
>>>
>>> Yours Irrespectively,
>>>
>>> John
>>>
>>>>>
>>>>> draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP
>>>>> Encapsulation extended to encode the tunnel encap to use for BUM
>>>>> traffic, but contrary to other E-VPN routes, relies on the Ethernet
>>>>> Tag field of the NLRI to encode the VNI/VSID.
>>>>
>>>> [JORGE] This is certainly a leftover from an old version where the
>>>> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI
>>>> should be encoded in the Label field in all the routes. This has to be corrected.
>>>>
>>>> In fact, section 5.1.3 says:
>>>>
>>>> 5.1.3 Constructing EVPN BGP Routes
>>>>
>>>> <snip>
>>>>
>>>> Accordingly, and
>>>>    specifically to support the option of locally assigned VNIs, the MPLS
>>>>    label field in the MAC Advertisement, Ethernet AD per EVI, and
>>>>    Inclusive Multicast Ethernet Tag routes is used to carry the VNI or
>>>>    VSID.  For the balance of this memo, the MPLS label field will be
>>>>    referred to as the VNI/VSID field. The VNI/VSID field is used for
>>>>    both local and global VNIs/VSIDs, and for either case the entire 24-
>>>>    bit field is used to encode the VNI/VSID value.
>>>>
>>>> <snip>
>>>
>>>
>>> [JD]  For the IMET route the MPLS label field is carried in the PMSI attribute.  I think we
>> need to ask everyone whether they
>>> used the Ethernet Tag or the PMSI attribute to carry the VNI
>>>
>>>
>>>>>>
>>>>>> There are minor things that could be improved in
>>>>>> draft-ietf-bess-evpn-overlay wrt. consistency with
>>>>>> draft-ietf-idr-tunnel-encaps :
>>>>>>
>>>>>> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it
>>>>>> would be better that draft-ietf-bess-evpn-overlay refers to
>>>>>> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512.
>>>>
>>>> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the
>>>> encapsulation extended community. There are a few implementations
>>>> using this community and it is enough when only the encapsulation type is needed.
>>>
>>>
>>> [JD]   I agree and the tunnel encaps draft does keep the EC
>>>
>>>
>>>>
>>>>>>
>>>>>> * I think it would be better to avoid the explicit list of encap
>>>>>> types in section 5.1.3, and rather refer to
>>>>>> draft-ietf-idr-tunnel-encaps instead
>>>>
>>>> [JORGE] I agree.
>>>
>>>
>>> [JD]  According to IANA, it allocated the five tunnels types to the
>>> overlay draft so I think we need to keep them
>>>
>>>
>>>>
>>>>>> * the following minor modification was proposed, but not yet incorporated:
>>>>>>
>>>>>>     John Drake, 2015-11-13 (to BESS ML):
>>>>>>>     For the overlay draft, replace this text in section 5.1.3:
>>>>>>>
>>>>>>>     "If the BGP Encapsulation extended community is not present,
>>>>>>> then the default MPLS encapsulation or a statically configured
>>>>>>> encapsulation is assumed."
>>>>>>>
>>>>>>>     With the following:
>>>>>>>
>>>>>>>     "Note that the MPLS encapsulation tunnel type is needed in
>>>>>>> order to distinguish between an advertising node that only
>>>>>>> supports non-MPLS encapsulations and one that supports MPLS and
>>>>>>> non-MPLS encapsulations.  An  advertising node that only supports
>>>>>>> MPLS encapsulation does not need to advertise any encapsulation
>>>>>>> tunnel types;  i.e.,  if the BGP Encapsulation extended community
>>>>>>> is not present, then either MPLS encapsulation or a statically
>>>>>>> configured encapsulation is assumed."
>>>>>>
>>>>>> I think this change is useful and should be incorporated, although
>>>>>> skipping the last sentence would be wise if the full list of
>>>>>> tunnel types is removed.
>>>
>>>
>>> [JD]  Fine with me either w/ or w/o the last sentence
>>>
>>>

---

From: Thomas Morin <[email-masked]>
Date: Wed, 15 Jun 2016 16:21:49 +0200

Sounds good.

Thanks,

-Thomas

2016-06-15, John E Drake:
> Comments inline.
>> From: Thomas Morin [mailto:[email-masked]]
>> Sent: Wednesday, June 15, 2016 8:47 AM
>> To: John E Drake; Rabadan, Jorge (Nokia - US); BESS; draft-ietf-bess-evpn-
>> Subject: draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re: [Idr] draft-ietf-
>> bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps)
>>
>> Hi John, Ali,
>>
>> 5.1.3 needed adjustments to be brought in sync, and indeed there were some changes in
>> last revision.
>>
>> - section 5.1.3 says "the MPLS label field in the [...] Inclusive Multicast Ethernet Tag routes is
>> used to carry the VNI" although the "Inclusive Multicast Ethernet Tag Route" has no "MPLS
>> label field"
>> - (directly related to the above) none of these section talks about using the MPLS field of
>> the PMSI Tunnel Attribute as the VNI, although the discussion below concluded that it is
>> what implementations actually do
>
>
> [JD] Accordingly, and specifically to support the option of locally assigned VNIs, the MPLS label1 field in the MAC Advertisement route, the MPLS label field in the Ethernet AD per EVI route, and the MPLS label field in the PMSI Tunnel Attribute of the Inclusive Multicast Ethernet Tag route are used to carry the VNI.
>
>
>> - also, section 9 now says "The Ethernet Tag field of this route is set as described in section
>> 5.1.3.", but I find this sentence useless and redundant (precisely because 5.1.3 already says
>> it and nothing would indicate that section 9 would be exempt of what 5.1.3 says)
>
>
> [JD]  We should strike the sentence.
>
>
>>
>> Additionally, it occurred to me that "the MPLS field" is not, strictly speaking, unambiguous
>> for MAC Advertisement routes, because the route actually has two MPLS fields.  The text
>> should just say "MPLS Label1 field" for the MAC/IP advertisement route.
>
>
> [JD]  See above.
>
>
>>
>> Best,
>>
>> -Thomas
>>
>>
>>> We put the VNI value in the MPLS label field of the PMSI attribute for all service types,
>> and we put a value in the Ethernet Tag field following the rules for each service type as
>> described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-
>> 5.1.3).
>>>
>>>> To: John E Drake; EXT - [email-masked]; BESS; IDR;
>>>> draft-ietf-bess-evpn- [email-masked]; Ali Sajassi (sajassi)
>>>> [JD] For the IMET route the MPLS label field is carried in the PMSI
>>>> attribute. I think we need to ask everyone whether they used the
>>>> Ethernet Tag or the PMSI attribute to carry the VNI
>>>>
>>>>
>>>> In case it helps, I’ve seen a few implementations running and they
>>>> all encode the VNI in the MPLS label field in the PTA. And a couple
>>>> of them, encode the VNI in the ethernet-tag, in addition to the MPLS
>>>> label in the PTA. In any case, I think section 9 contradicts section 5.1.3 and should be
>> clarified.
>>>>
>>>> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI,
>>>> and **Inclusive Multicast Ethernet Tag** routes is used to carry the VNI or VSID."
>>>>
>>>> Thanks.
>>>> Jorge
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>> traffic, but contrary to other E-VPN routes, relies on the
>>>>>>> Ethernet Tag field of the NLRI to encode the VNI/VSID.
>>>>>>
>>>>>> VNI/VSID was encoded in the ethernet tag for all the routes. The
>>>>>> VNI should be encoded in the Label field in all the routes. This has to be corrected.
>>>>>>
>>>>>>>>> non-MPLS encapsulations.  An  advertising node that only
>>>>>>>>> supports MPLS encapsulation does not need to advertise any
>>>>>>>>> encapsulation tunnel types;  i.e.,  if the BGP Encapsulation
>>>>>>>>> extended community is not present, then either MPLS
>>>>>>>>> encapsulation or a statically configured encapsulation is assumed."
>>>>>>>>
>>>>>>>> I think this change is useful and should be incorporated,
>>>>>>>> although skipping the last sentence would be wise if the full
>>>>>>>> list of tunnel types is removed.
>>>>>
>>>>>

---

From: John E Drake <[email-masked]>
Date: Wed, 15 Jun 2016 14:13:49 +0000

Thomas,

Comments inline.

Yours Irrespectively,

John

[JD]  See above.

> >>> attribute.  I think we