Hi Bruno, On Fri, Jun 30, 2017 at 8:31 AM, <bruno.decra...@orange.com> wrote:
> Hi Alia, > > > > More inline [Bruno2] > > > > *From:* Alia Atlas [mailto:akat...@gmail.com] > *Sent:* Thursday, June 29, 2017 11:09 PM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* OSPF List; draft-ietf-ospf-encapsulation-...@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.decra...@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:akat...@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- > 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:akat...@gmail.com] > Sent: Tuesday, June 20, > 2017 5:27 PM > > > > On Mon, Jun 19, 2017 at 9:19 PM, Xuxiaohu <xuxia...@huawei.com> wrote: > > > > > Hi Alia, > > > > > > > > > > > > Thanks a lot for your AD review. Please see our response inline. > > > > > > > > > > > > *发件人**:* Alia Atlas [mailto:akat...@gmail.com <akat...@gmail.com>] > > > *发送时间**:* 2017年6月15日 6:56 > > > *收件人**:* OSPF List; draft-ietf-ospf-encapsulation-...@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. > >
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
