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

[Alia Atlas <[e-mail]>]

Hi Acee,

On Fri, Jun 30, 2017 at 11:52 AM, Acee Lindem (acee) <[e-mail]> wrote:

> Hi Alia, Bruno,
>
> From: OSPF <[e-mail]> on behalf of Alia Atlas <
> [e-mail]>
> Date: Friday, June 30, 2017 at 11:30 AM
> To: Bruno Decraene <[e-mail]>
> Cc: OSPF WG List <[e-mail]>, "draft-ietf-ospf-
> [e-mail]" <[e-mail]>
> Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03
>
> Hi Bruno,
>
> On Fri, Jun 30, 2017 at 8:31 AM, <[e-mail]> wrote:
>
>> Hi Alia,
>>
>>
>>
>> More inline [Bruno2]
>>
>>
>>
>> *From:* Alia Atlas [mailto:[e-mail]]
>> *Sent:* Thursday, June 29, 2017 11:09 PM
>> *To:* DECRAENE Bruno IMT/OLN
>> *Cc:* OSPF List; [e-mail]; 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, <[e-mail]> 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:[e-mail]]
>> > 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:[e-mail]]  > Sent: Tuesday, June 20,
>> 2017 5:27 PM
>> >
>>  > On Mon, Jun 19, 2017 at 9:19 PM, Xuxiaohu <[e-mail]> wrote:
>>  >
>>  > > Hi Alia,
>>  > >
>>  > >
>>  > >
>>  > > Thanks a lot for your AD review. Please see our response inline.
>>  > >
>>  > >
>>  > >
>>  > > *发件人**:* Alia Atlas [mailto:[e-mail] <[e-mail]>]
>>  > > *发送时间**:* 2017年6月15日 6:56
>>  > > *收件人**:* OSPF List; [e-mail]
>>  > > *主题**:* 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.
>>
>>
>