Re: [Isis-wg] [spring] comment on draft-ietf-isis-segment-routing-extensions-02

["Stefano Previdi (sprevidi)" <[e-mail]>]

Multiple use cases documents. Draft-filsfils-segment-routing-use-cases being one.

s.


Sent from mobile


-----Original Message-----
From: Hannes Gredler [[e-mail]]
Received: Monday August 4, 2014, 08:55
To: Acee Lindem (acee) [[e-mail]]; Stefano Previdi (sprevidi) [[e-mail]]; Chris Bowers [[e-mail]]
CC: [e-mail] [[e-mail]]; [e-mail] [[e-mail]]
Subject: Re: [Isis-wg] [spring] comment on draft-ietf-isis-segment-routing-extensions-02


ok, so my understanding is:

- have a standalone document which describes the usage of 'external'
protocols (LDP, BGP-LU, RSVP, stacked labels, egress protection)
and add it as a reference to all the SR one-the-wire protocol specs.
(OSPFv2, OSPFv3, IS-IS, BGP-LS).

agreed ?

/hannes

On 8/1/14 23:51, Acee Lindem (acee) wrote:
> This is my preference for the protocol extension drafts.
> Thanks,
> Acee
>
> On 8/1/14, 3:48 PM, "Stefano Previdi (sprevidi)" <[e-mail]>
> 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:[e-mail]]
>>> Sent: Friday, August 01, 2014 1:54 AM
>>> To: Uma Chunduri
>>> Cc: Chris Bowers; [e-mail]; [e-mail]
>>> 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:[e-mail]] On Behalf Of Chris
>>>> Bowers
>>>> Sent: Thursday, July 31, 2014 2:42 PM
>>>> To: [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/isis-wg
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg