Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Alia Atlas <akatlas@gmail.com> Fri, 30 June 2017 15:59 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B624128961; Fri, 30 Jun 2017 08:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdfbpweEwTKP; Fri, 30 Jun 2017 08:59:24 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E8412F27D; Fri, 30 Jun 2017 08:59:24 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id w126so113961327wme.0; Fri, 30 Jun 2017 08:59:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GtAOe3mrmlo/CtM/ZJRyvAk0GmcvfIhUMRgXgjKUpd0=; b=Za3ukZFhHBpMLQyPqnelwlGDgv53rU/QJgube/RqQequOXnHdonoCsLx33tEL7brVu kze1A12agKMa9ErjUirj18xJckcNZSED8gtFguZuhl+hfHGzzs9Zu5fXp1fbav3kOzfZ FCqxwAn6xvJEqq2OBDZ5rMVxS9QzNYpFnmtgGDREknX79V/zbOBC1AydEywOJ+ZHypWa Ppd8Ln5AL5h5EQaSr6Bcx7fgdJILxA4QDCAA0PGZDWCJgNKrXBTQcGW+mno8TxnRtrOC POp6BIl2Dh350bcPNNIfZk7NZ9ZLpN5YEhiqeeUxAvS+2AgCXVQbDWj4o73hhKVsADSL 9lFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GtAOe3mrmlo/CtM/ZJRyvAk0GmcvfIhUMRgXgjKUpd0=; b=BxByv5MzvZspcEnP10h9N8qXjqS4PaHlYq1jbQmrhcFaUv2cgRLdd/JtAwkUOqeAxO WDbXUOlguQtOtk3lIoaJ/bVZJAHRaER5qKcaHCcezpthNDg0UTbSDi20EKheAka0VXfX ic+0gx3Bh3bHyVw5EG+HI9qp2tzbwoFVQvu3oR1di1H5WGf2Nd8G+0Or8hxZJwJmqT1/ 2JKkxglfD6E5R8rg+BRh+BDzQ5RHr8T+BiGF4GfZ7Bn9PbGqg+YtZJc9JI5xBgQ5gUmu fx08CWoiQNu9jO76qSzVT67G8+p3ZeszfyVfOI6jpC1/062wglgx8oaxjhNs9VG7I3Rl WpfA==
X-Gm-Message-State: AKS2vOwC/1naJvWUQBF6OYmoMQQh8oQ2vTXasRAl8lsm4qedHhEye3I2 IO/j8QrhuyIGpeGQ5mnvAygVXYty7Q==
X-Received: by 10.28.211.132 with SMTP id k126mr16334944wmg.109.1498838362552; Fri, 30 Jun 2017 08:59:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.130.179 with HTTP; Fri, 30 Jun 2017 08:59:21 -0700 (PDT)
In-Reply-To: <D57BEA97.B6E22%acee@cisco.com>
References: <CAG4d1rfJPTyz-nENp2ViJYg14BCctGAAzt+TD3E9zEdejpqJaA@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBC446D@NKGEML515-MBX.china.huawei.com> <CAG4d1rdaPeUD4Vdgh8BGdF73mxc1Px=aaTj=7GzcaF+0JGuxKw@mail.gmail.com> <29949_1498471189_5950DB15_29949_382_1_53C29892C857584299CBF5D05346208A477AC986@OPEXCLILM21.corporate.adroot.infra.ftgroup> <CAG4d1rdBsH8j3u6yVppzUKPwL-T44nHbH-kuw-SFfT7voqhoJQ@mail.gmail.com> <26797_1498825901_595644AD_26797_68_1_53C29892C857584299CBF5D05346208A477E050A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <CAG4d1reTWATBUMSU8R6_FgpsvwLebrBkdt+AYN-vQTXhYtKE+A@mail.gmail.com> <D57BEA97.B6E22%acee@cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 30 Jun 2017 11:59:21 -0400
Message-ID: <CAG4d1re-MeKB4M=scTW3FhbnbVXPbNU0R9r7TdOxSbcMs7xBvw@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Bruno Decraene <bruno.decraene@orange.com>, OSPF List <ospf@ietf.org>, "draft-ietf-ospf-encapsulation-cap@ietf.org" <draft-ietf-ospf-encapsulation-cap@ietf.org>
Content-Type: multipart/alternative; boundary="001a11467e3e2d025a05532f8015"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/BM5YYQWn0BHtIEdJz00L5B_-KEs>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jun 2017 15:59:29 -0000

Hi Acee,

On Fri, Jun 30, 2017 at 11:52 AM, Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Alia, Bruno,
>
> From: OSPF <ospf-bounces@ietf.org> on behalf of Alia Atlas <
> akatlas@gmail.com>
> Date: Friday, June 30, 2017 at 11:30 AM
> To: Bruno Decraene <bruno.decraene@orange.com>
> Cc: OSPF WG List <ospf@ietf.org>rg>, "draft-ietf-ospf-
> encapsulation-cap@ietf.org" <draft-ietf-ospf-encapsulation-cap@ietf.org>
> Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03
>
> Hi Bruno,
>
> On Fri, Jun 30, 2017 at 8:31 AM, <bruno.decraene@orange.com> wrote:
>
>> Hi Alia,
>>
>>
>>
>> More inline [Bruno2]
>>
>>
>>
>> *From:* Alia Atlas [mailto:akatlas@gmail.com]
>> *Sent:* Thursday, June 29, 2017 11:09 PM
>> *To:* DECRAENE Bruno IMT/OLN
>> *Cc:* OSPF List; draft-ietf-ospf-encapsulation-cap@ietf.org; Xuxiaohu
>> *Subject:* Re: AD review of draft-ietf-ospf-encapsulation-cap-03
>>
>>
>>
>> Hi Bruno,
>>
>>
>>
>> Thanks for the updated draft - more in-line.
>>
>>
>>
>> On Mon, Jun 26, 2017 at 5:59 AM, <bruno.decraene@orange.com> wrote:
>>
>> Hi Alia,
>>
>> Many thanks for the useful review.
>> -04 has just been published. I believe it address your first pass of
>> comments.
>> Htmlized:       https://datatracker.ietf.org/
>> doc/html/draft-ietf-ospf-encapsulation-cap-04
>> Diff:           https://www.ietf.org/rfcdiff?
>> url2=draft-ietf-ospf-encapsulation-cap-04
>>
>>
>>
>> Main changes:
>> - aligning with  I-D.ietf-idr-tunnel-encaps rather than RFC 5512.
>> - adding 2 sub-TLV coming from I-D.ietf-idr-tunnel-encaps: IP QoS Field,
>> UDP Destination Port. Note that the first one is currently called "IPv4 DS
>> Field" in the IDR draft. I've commented on IDR that this is IPv4 specific
>> with no IPv6 counterpart.
>>
>>
>>
>> [Alia] The text for the UDP Destination Port (Sec 6.6) is wrong - it's
>> just copied from Sec 6.5.
>>
>> [Bruno2] thanks, fixed
>>
>> I agree with you on the need for the IP QoS field to represent both IPv6
>> as well as IPv4; it also just talks about the DS field - but that's 6
>> bits.  Are the ECN bits included?  That's a conversation for IDR.
>>
>> [Bruno2] agreed (that’s for IDR)
>>
>>
>>
>> Waiting for the resolution. We need the BGP and IGP draft to be aligned.
>> - removed registry "IGP Tunnel Encapsulation Type" and pointing to
>> existing registry "BGP Tunnel Encapsulation Type"
>> - (editorial) Sub-TLV of the Tunnel Encapsulation Attribute are grouped
>> in a dedicated section (§6)
>> - clarification that for all but one, those sub-TLV are defined in
>> I-D.ietf-idr-tunnel-encaps, from a syntax, semantic and usage standpoint.
>> - color Sub-TLV better defined (as not aligned with the IDR draft)
>> - added a section about the usage of the Tunnel Encapsulation attribute
>> (§7)
>> - a significant rule added: " A tunnel MUST NOT be used if there is no
>> route toward the IP address
>>    specified in the Endpoint Sub-TLV or if the route is not advertised
>>    by the router advertising the Tunnel Encapsulation attribute
>>    advertising this tunnel. "
>>
>>
>> Some follow up on some of your points that I had missed in previous
>> answer:
>>
>> > From: Alia Atlas [mailto:akatlas@gmail.com]
>> > Sent: Thursday, June 15, 2017 12:56 AM
>> [...]
>> > (does variable length fields based upon the allocated type cause issues
>> for OSPF sub-TLV parsing???)
>>
>> I guess that you are referring to
>> "   o  Sub-TLV Length (1 or 2 octets): the total number of octets of the
>>       sub-TLV value field.  The Sub-TLV Length field contains 1 octet if
>>       the Sub-TLV Type field contains a value in the range from 1-127.
>>       The Sub-TLV Length field contains two octets if the Sub-TLV Type
>>       field contains a value in the range from 128-254."
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-
>> encaps-06#section-2
>>
>> The IGP draft does not use this. It uses a fixed 1-octet length field:
>>     " Sub-TLV Length (1 octet): Unsigned 8-bit integer indicating the
>>       total number of octets of the Sub-TLV value field."
>> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encaps
>> ulation-cap-04#section-5
>>
>>
>>
>> [Alia] I think that there is still clarification on what to do if (in the
>> future) a sub-TLV that
>>
>> used the 2-octet length couldn't fit into a 1-octet length. I know this
>> is currently hypothetical,
>>
>> so all I'm looking for is a statement about the difference and that such
>> sub-TLVs are not supported
>>
>> without further extensions.
>>
>>
>>
>>  [Bruno2] There are 2 “Tunnel Encapsulation Attribute Types” registries:
>>
>> - one for BGP, which allow length of 1 or 2 octets (as per the
>> draft-ietf-idr-tunnel-encaps-06 because RFC 5512 only allowed for 1
>> octet)
>>
>> - one for IGP, which allow length of 1 octet
>>
> Even though it is unlikely to be required, can we just go with 2 octet
> type and length for the tunnel attribute Sub-TLVs consistent with the TLV
> format in RFC 7770? Seems like this would simplify things – I guess we are
> worried about IS-IS consistency?
>

That works too & is a cleaner solution.  I had forgotten about the sizes of
sub-tlvs in RFC 7770.

Thank you,
Alia



> Thanks,
> Acee
>
>
>
>
>
>>
>> For the IGP, there is no provision/future possibility to use a two-octets
>>  length sub-TLV.
>>
>> So yes, the length is limited, but this is not specific to this sub-TLV.
>> All IGP/IETF/ISO…. TLVs share the same limitation that the size of the
>> length field is predefined and fixed. So nothing new IMHO.
>>
>> The only specific thing with this document is the filiation with the BGP
>> document. If BGP were to define a two-octets length sub-TLV, it could not
>> be retro-fitted in the IGP. One option would be to split the information
>> into multiple sub-TLVs, but this is still limited. Is this this relation
>> with the BGP sub-TLV that you’d like to be highlighted? If so, I can
>> propose a new section
>>
>> “6.7 Future sub-TLV
>>
>> draft-ietf-idr-tunnel-encaps similarly defines Tunnel Encapsulation
>> Attribute Sub-TLVs but IGP and BGP have separate IANA registries allowing
>> for separate sub-TLV definitions. If the same information is to be
>> advertised for both IGP and BGP tunnel encapsulation, it’s RECOMMENDED to
>> use the same syntax, semantic and code point. However, it is to be noted
>> that the "BGP Tunnel
>>
>>    Encapsulation Attribute Sub-TLVs" registry allows for sub-TLV with two
>> octets of length, while the “IGP Tunnel Encapsulation Attribute Types”
>> registry only allows to octet of length. Hence the two-octets BGP Tunnel
>>
>>    Encapsulation Attribute Sub-TLVs won’t be able to be defined for IGP
>> Tunnels. Eventually, their information may be split over multiple
>> sub-TLVs.”
>>
>>
>>
>> Is this what you are looking for?
>>
>> Alternatively the IGP registry could also define such two lengths, but to
>> be honest, I’m reluctant to introduce such a “hack” in IGP. I would fear
>> bugs with the introduction of a type having a two-octet length, with
>> possibly significant consequences in a link state IGP.
>>
>>
>>
>> BTW, I’ve just noticed that BGP and IGP registries have different names
>> as the name of the BGP registry has changed since RFC 5512. I’m fixing this
>>
>> OLD: IGP Tunnel Encapsulation Attribute Types
>>
>> NEW: IGP Tunnel Encapsulation Attribute Sub-TLVs
>>
>>
> [Alia] I thought the draft was now using the BGP Tunnel Encapsulation
> Attribute Sub-TLVs??
> This draft just needs a statement that says "In BGP, as defined in
> [draft-ietf-idr-tunnel-encaps], Sub-TLVs with types 128-254 have a
> two-octet length field.  In OSPF, there is no support for a two-octet
> length field; sub-TLVs in this range cannot be used in OSPF unless the
> value field's length is known to fit in one octet."
>
>
>>
>>
>> > Semantics and behavior need to be specified - not just the encodings
>>
>> Agreed.
>> Note however that the behavior is more complex in the BGP draft, because
>> the Tunnel Attribute is attached to BGP routes, which can be of various
>> SAFI with their own semantic and usage (e.g. GRT vs VPN/overlay case,
>> labeled/unlabeled...) and their interaction with the different kind of
>> tunnels (GRT vs VPN, labeled vs unlabeled). This is not the case in the IGP
>> draft which only signals the tunnel itself (discovery, parameters).
>>
>>
>>
>> [Alia] Sure - Sec 7 helps a lot.
>>
>> What isn't clear though is how tunnels that require setup are handled.
>> In Sec 5 of draft-ietf-idr-tunnel-encaps-06, I see
>>
>> "The tunnel type is supported (i.e., router R knows how to set up tunnels
>> of that type, how to create the encapsulation header for tunnels of that
>> type, etc.)" as part of the discussion of what is a "feasible" tunnel.
>> Similar language would help in Sec 7.
>>
>> [Bruno2]
>>
>> Both IDR and OSPF drafts have the same text regarding tunnel setup: “   Note that some tunnel types may require the execution of an explicit
>>
>>    tunnel setup protocol before they can be used for carrying data.
>>
>>    Other tunnel types may not require any tunnel setup protocol.”
>>
>>
>>
>
> As the IDR draft defines the IANA registry for encapsulation type, it also have the following sentence “Whenever a new Tunnel Type TLV is defined, the specification of that
>>
>>    TLV must describe (or reference) the procedures for creating the
>>
>>    encapsulation header used to forward packets through that tunnel
>>
>>    type. » I don’t think that this is needed in the IGP draft since it does not define such registry.
>>
>>
>>
>>
>>
>> Since you specifically refer to a text in section 5 of
>> draft-ietf-idr-tunnel-encaps-06, I think that for the ospf draft the
>> related text is in section 7 and I’m proposing the following change
>>
>> OLD: The decision to use that tunnel, is driven by policy on the ingress
>> router.
>>
>> NEW: The decision to use that tunnel is driven by the capability of the
>> ingress router to support the encapsulation type and the policy on the
>> ingress router.
>>
>
> [Alia] That sounds good.
>
>
>>
>>
> [Alia] Finally, from a process perspective, I think that there has been
>> sufficient technical change that another short WGLC is appropriate.  Please
>> do update the draft first.  Then, we can do an IETF Last Call targeting an
>> IESG telechat in August.
>>
>> [Bruno2] ok. Waiting for your feedback before uploading the new version.
>>
>
> [Alia] Please do.
>
>
>
>> Thanks,
>>
>> Regards,
>>
>> --Bruno
>>
>>
>>
>> Regards,
>>
>> Alia
>>
>>
>>
>>
>>
>>
>> Thanks again for the careful review and the useful comments.
>>
>> Regards,
>> --Bruno
>>
>> > From: Alia Atlas [mailto:akatlas@gmail.com]  > Sent: Tuesday, June 20,
>> 2017 5:27 PM
>> >
>>  > On Mon, Jun 19, 2017 at 9:19 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
>>  >
>>  > > Hi Alia,
>>  > >
>>  > >
>>  > >
>>  > > Thanks a lot for your AD review. Please see our response inline.
>>  > >
>>  > >
>>  > >
>>  > > *发件人**:* Alia Atlas [mailto:akatlas@gmail.com <akatlas@gmail.com>]
>>  > > *发送时间**:* 2017年6月15日 6:56
>>  > > *收件人**:* OSPF List; draft-ietf-ospf-encapsulation-cap@ietf.org
>>  > > *主题**:* AD review of draft-ietf-ospf-encapsulation-cap-03
>>
>>  > >
>>  > >
>>  > >
>>  > > As is customary, I have done my AD review of draft-ietf-ospf-
>>  > > encapsulation-cap-03.
>>  > >
>>  > > First, I would like to thank the authors - Xiaohu, Bruno, Robert,
>> Luis,
>>  > > and Luay - for their work on this useful document.
>>  > >
>>  > >
>>  > >
>>  > > I do have a few concerns that need addressing before the draft can
>>  > > progress.
>>  > >
>>  > >
>>  > >
>>  > > [Bruno/Xiaohu] Many thanks for your useful comments.
>>  > >
>>  > > Following your comments, we believe it would be simpler and better
>> to not
>>  > > create a new IANA registry for ”IGP  Tunnel Encapsulation Attribute
>> Types”
>>  > > but rather reuse the existing BGP one:
>>  > >
>>  > > https://www.iana.org/assignments/bgp-parameters/
>>  > > bgp-parameters.xhtml#tunnel-types
>>  > >
>>  >
>>  > Given that the sub-TLVs available depend on the tunnel type, I think
>> this
>>  > makes sense.
>>  >
>>  >
>>  >
>>  > > [Bruno/Xiaohu] BTW when this OSPF extension has been defined, it has
>> been
>>  > > modeled based on RFC 5512. However, as of today, the BGP extension
>> is been
>>  > > redefined in draft-ietf-idr-tunnel-encaps, sometimes. Which normative
>>  > > reference should be use?
>>  > >
>>  > > - as of today, RFC 5512 is probably the right one as
>>  > > draft-ietf-idr-tunnel-encaps has not passed WG LC and may never be
>>  > > published as RFC (IDR requires 2 implementations. I think RFC 5512
>> has not
>>  > > been implemented hence we may question whether
>> draft-ietf-idr-tunnel-encaps
>>  > > will be…)
>>  > >
>>  > > - in some hypothetical future, draft-ietf-idr-tunnel-encaps may
>> obsolete
>>  > > RFC 5512
>>  > >
>>  >
>>  > Judging from the two partial implementations in the IDR wiki, I'm not
>> quite
>>  > as concerned.  That said, are you certain that there aren't
>> explanations
>>  > and behaviors that are clarified in draft-ietf-idr-tunnel-encaps that
>>  > aren't in RFC 5512?  Certainly, some of the tunnel types that were
>>  > mentioned in the OSPF registry are from the former.
>>  >
>>  >
>>  > > Major:
>>  > >
>>  > >
>>  > >
>>  > > 1)  First, the draft talks about what information is sent - but
>> nothing
>>  > > about how it is to be understood or used.  That'd be ok if there
>> were a
>>  > > clear reference to a document that discussed the related
>> procedures.  A
>>  > > quick scan of draft-ietf-idr-tunnel-encaps-06 seems that it may be
>> the
>>  > > right place to start - but it's procedures are BGP-focused and while
>> there
>>  > > are many similarities, there may be interesting differences as well.
>>  > >
>>  > >
>>  > >
>>  > > [Bruno/Xiaohu] We’ll clarify that the 3 sub-TLV (§5.1-§5.3) are
>>  > > normatively defined in RFC 5512, from a format, semantic and usage
>>  > > standpoint. And that there code point are allocated in respectively
>> the
>>  > > following IANA registries: BGP Tunnel Encapsulation Attribute Tunnel
>> Types,
>>  > > BGP Tunnel Encapsulation Attribute Sub-TLVs. As per you comment, we
>> need to
>>  > > clarify the 5.4 color Sub-TLV. Proposed text:
>>  > >
>>  > > The Color Sub-TLV value is a 4-octet unsigned integer. Its semantic
>> and
>>  > > usage are the same as the Color Value, from the Color Sub-TLV
>> defined in
>>  > > RFC 5512 section 4.3 (*)
>>  > >
>>  > >
>>  > >
>>  > > For instance, for the Color sub-TLV, is the 4 byte color value
>> expected to
>>  > > represent the same meaning in OSPF as in BGP?
>>  > >
>>  > >
>>  > >
>>  > > [Bruno/Xiaohu]Yes.
>>  > >
>>  > >
>>  > >
>>  > >   Can a BGP route with a particular color extended community then
>> have the
>>  > > OSPF tunnel to use selected from only those tunnels with the same
>> color?
>>  > >
>>  > >
>>  > >
>>  > >   What does the Color TLV mean in a purely OSPF context?
>>  > >
>>  > >
>>  > >
>>  > > [Bruno/Xiaohu] idem as in the IDR context.  It’s a color used to
>> define
>>  > > policy. The application using those tunnels, may use this color as
>> an input
>>  > > for its policy when choosing the tunnel to use (or not use).
>>  > >
>>  > > We can add this text if needed.
>>  > >
>>  > >
>>  > Yes, I think that is needed.  In BGP, since a route can have
>> communities,
>>  > it is easy to just have a "must match color" rule (though one could
>> picture
>>  > a community that means match-any-tunnel-but-this-color).  For OSPF,
>> if the
>>  > intention of the use for this information is an external application,
>> that
>>  > needs to be clearly stated.
>>  >
>>  > There needs to be enough text so that two implementations can actually
>> use
>>  > the functionality - not merely signal it - and that is generally what
>> is
>>  > missing in the document.
>>  >
>>  >    Sec 7 of draft-ietf-idr-tunnel-encaps-06 ("However, suppose that
>> one of
>>  > > the TLVs in U2's Tunnel Encapsulation attribute contains the Color
>>  > > Sub-TLV.  In that case, packet P SHOULD
>>  > >
>>  > >    NOT be sent through the tunnel identified in that TLV, unless U1
>> is
>>  > >    carrying the Color Extended Community that is identified in U2's
>>  > >    Color Sub-TLV.") doesn't seem to strictly apply.
>>  > >
>>  > >
>>  > >
>>  > > [Bruno/Xiaohu] Would new clarification added above (*) be enough? If
>> not,
>>  > > a priori, I’d rather improve the definition of section 5.4 defining
>> this
>>  > > color sub-TLV, in order for it to generally apply to any text.
>> (rather than
>>  > > trying to patch the specific above text from Sec 7)
>>  > >
>>  >
>>  > I would be happy for you to fix it where makes the most sense to you.
>> My
>>  > review suffers from the usual issue of commenting mostly on what is
>> there
>>  > in the order and location it is presented.
>>  >
>>  >
>>  > > Semantics and behavior need to be specified - not just the
>> encodings, and
>>  > > that is all this draft currently has.
>>  > >
>>  > >
>>  > >
>>  > >
>>  > >
>>  > > 2)  Sec 5.1 and Sec 5.2 refer to the format of the Encapsulation
>> Sub-TLV
>>  > > and Protocol Sub-TLV coming from draft-ietf-idr-tunnel-encaps-06 -
>> but
>>  > > that draft defines not merely the format, but allocates an IANA
>> registry
>>  > > for additional sub-types that can appear and defines the format and
>>  > > contents of the sub-TLV based upon the tunnel type.   I'm nearly
>> certain
>>
>>  > > that you mean that these sub-tlvs use not merely the same format
>> (*does
>>  > > variable length fields based upon the allocated type cause issues
>> for OSPF
>>  > > sub-TLV parsing???*) but can contain any values and sub-TLVs defined
>> in
>>  > > the relevant IANA registry. As it is written now, there is no
>> reference to
>>  > > the registry or ability to easily support more tunnel types in the
>> future
>>
>> ____________________________________________________________
>> _____________________________________________________________
>>
>> 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.
>>
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>>
>