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