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

[Alia Atlas <[e-mail]>]

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-
> encapsulation-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
>
>
>
> 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.
>
>