This is my preference for the protocol extension drafts. Thanks, Acee On 8/1/14, 3:48 PM, "Stefano Previdi (sprevidi)" <[email protected]> wrote:
>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-0 >>>5 >>> 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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
