my point is that description of use cases should be on a separate document in order to avoid replication of text between isis and ospf drafts.
Protocol extensions drafts should be focused on bits/bytes to be carried by the protocol. I think there's agreement on this. s. On Aug 1, 2014, at 8:57 PM, Chris Bowers wrote: > I disagree. The proposed text contains four Binding TLV usage examples which > are not qualitatively different from the two usage examples already included > in section 2.4.3 of draft-ietf-isis-segment-routing-extensions-02. > Additional usage examples are needed to clarify how the TLVs and sub-TLVs > defined in this document should be used, without ambiguity. > > As an example of the lack of clarity in the current text, > draft-ietf-isis-segment-routing-extensions-02 contains two different sub-TLVs > for specifying SID/Label values in the Binding TLV. The two options are the > SID/Label Sub-TLV (section 2.3) and the Prefix-SID Sub-TLV (section 2.1). > The current text does not clearly explain under what circumstances the two > different sub-TLVs should be used in the Binding TLV. The proposed text > makes the usage clear by means of examples. > > Chris > > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:[email protected]] > Sent: Friday, August 01, 2014 1:54 AM > To: Uma Chunduri > Cc: Chris Bowers; [email protected]; [email protected] > Subject: Re: [Isis-wg] comment on > draft-ietf-isis-segment-routing-extensions-02 > > Uma, > > I agree. > > I think we also explicitly stated this during our meeting in Toronto (from > the minutes): > > -------------------------------------------------------------------- > Uma: Needed to reference use cases in Hannes' draft. > Hannes: Perhaps what we could do is add some practical examples for > RSVP, BGP, and LDP LSPs binding. Not formal use cases. > Stefano: Would rather not go into applications in this ISIS draft. > Peter Psenak: Should go into a separate document that could be > referenced from both ISIS and OSPF. > Alia Atlas: There is a SPRING WG for such a document. > ------------------------------------------------------------------- > > Now, note that: > draft-filsfils-spring-segment-routing > draft-filsfils-spring-segment-routing-ldp-interop > > describe the use case of the SR Mapping Server that is implemented using the > Binding TLV. > > As you suggested, Hannes drafts can be combined so to produce a use-case > document (in spring) for the Binding TLV RSVP-based use-cases. > > > s. > > > On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote: > >> [CC'ed Spring WG] >> >> I agree with what Chris said below in principle. But all this should not be >> obviously part of ISIS/IGP extensions WG documents.. >> >> Use cases for binding TLVs are explained in great details in 2 key >> documents (had to shuffle through to get here) - >> >> 1. >> http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-05 >> 2. http://tools.ietf.org/html/draft-gredler-spring-mpls-06 >> >> IMO, both are very useful documents. >> It would be good to combine both of these and publish as a "spring " >> document and eventually it should progress there. >> AFAICT, Both ISIS and OSPF should refer the same eventually to get more >> clarity and use of binding TLVs described currently. >> >> -- >> Uma C. >> >> From: Isis-wg [mailto:[email protected]] On Behalf Of Chris >> Bowers >> Sent: Thursday, July 31, 2014 2:42 PM >> To: [email protected] >> Subject: [Isis-wg] comment on >> draft-ietf-isis-segment-routing-extensions-02 >> >> All, >> >> The current text of draft-ietf-isis-segment-routing-extensions-02 does not >> clearly explain the usage of the Binding TLV for advertising LSPs created >> using other protocols. I would like to propose the following text to be >> included as section 2.5 . >> >> Thanks, >> Chris >> >> ---------------- >> >> 2.5 Binding TLV usage examples >> >> This section gives examples of using the Binding TLV to advertise SID/label >> bindings associated with RSVP-TE, LDP, and BGP labeled-unicast LSPs. It >> also includes an example of advertising a context-id for egress node >> protection. All of the examples assume that the Binding TLV weight=1 and >> metric=100. >> >> 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV >> >> Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with >> router-id=10.4.4.4, with ER0 = (192.1.2.2 [strict], 192.2.3.2 [strict], >> 192.3.4.2 [strict]). R1 can advertise a locally significant label binding >> for this LSP (with label value=1099) using the following values and >> sub-TLVs in the Binding TLV. >> >> Binding-TLV: F-bit=0, M-bit=0, weight=1, range=1, prefix length=32, >> FEC prefix=10.4.4.4 SID/Label Sub-TLV: label=1099 ERO Metric sub-TLV: >> metric=100 >> IPv4 ERO sub-TLV: L-bit=0, IPv4 address=192.1.2.2 >> IPv4 ERO sub-TLV: L-bit=0, IPv4 address=192.2.3.2 >> IPv4 ERO sub-TLV: L-bit=0, IPv4 address=192.3.4.2 >> >> 2.5.2 Advertising an LDP LSP using the Binding TLV >> >> Assume that R5 has learned a FEC-label binding via LDP for FEC=10.8.8.8/32. >> R5 can advertise a locally significant label binding for this LSP (with >> label value=5099) using the following values and sub-TLVs in the Binding >> TLV. >> >> Binding TLV: F-bit=0, M-bit=0, weight=1, range=1, prefix length=32, >> FEC prefix=10.8.8.8 SID/Label Sub-TLV: label=5099 ERO Metric sub-TLV: >> metric=100 >> IPv4 ERO sub-TLV: L-bit=1, IPv4 address=10.8.8.8 >> >> 2.5.3 Advertising a BGP labeled-unicast LSP using the Binding TLV >> >> Assume that R9 has used BGP labeled-unicast to learn a label binding for >> prefix 10.15.15.15/32 with BGP next-hop=10.12.12.12. R9 can advertise a >> locally significant label binding for this LSP (with label value=7099) >> using the following values and sub-TLVs in the Binding TLV. >> >> Binding-TLV: F-bit=0, M-bit=0, weight=1, range=1, prefix length=32, >> FEC prefix=10.15.15.15 SID/Label Sub-TLV: label=7099 ERO Metric >> sub-TLV: metric=100 >> IPv4 ERO sub-TLV: L-bit=1, IPv4 address=10.12.12.12 >> >> 2.5.4 Advertising a context-id for egress node protection using the >> Binding TLV >> >> Assume that R22 is configured in the protector role to provide egress node >> protection for R21 using context-id=10.0.0.21. R22 can advertise the label >> associated with this context-id (with label value=8099) using the following >> values and sub-TLVs in the Binding TLV. >> >> Binding TLV: F-bit=0, M-bit=1, weight=1, range=1, prefix length=32, >> FEC prefix=10.0.0.21 SID/Label Sub-TLV: label=8099 >> >> ---------------- >> >> >> >> _______________________________________________ >> Isis-wg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
