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

From: Uma Chunduri <[email-masked]>
Date: Fri, 1 Aug 2014 18:01:54 +0000

Stefano,

Sure. I agree.

Thanks for pointing out mapping server overlap here and usage of Binding TLVs.

IMO, it's good to refer these explicitly from the binding TLV sub-sections of IGP documents (as things are not obvious as is with the case for  node-sid/adj-sid).

--
Uma C.

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 11:54 PM
To: Uma Chunduri
Cc: Chris Bowers; [email-masked]; [email-masked]
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-masked]] On Behalf Of Chris 
> Bowers
> Sent: Thursday, July 31, 2014 2:42 PM
> To: [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Chris Bowers <[email-masked]>
Date: Fri, 1 Aug 2014 18:57:26 +0000

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-masked]] 
Sent: Friday, August 01, 2014 1:54 AM
To: Uma Chunduri
Cc: Chris Bowers; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02

Uma,

I agree.

Now, note that:

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 1 Aug 2014 19:48:59 +0000

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 1 Aug 2014 21:51:14 +0000

This is my preference for the protocol extension drafts.
Thanks,
Acee 

On 8/1/14, 3:48 PM, "Stefano Previdi (sprevidi)" <[email-masked]>
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
>> 
>> Subject: Re: [Isis-wg] comment on
>> 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.
>> 
>> 
>>> I agree with what Chris said below in principle. But all this should
>>>not be obviously part of ISIS/IGP extensions WG documents..
>>> 
>>> 1.       
>>>http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-0
>>>5
>>> 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.
>>> 
>>> 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
>>> 
>>> ----------------
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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. 
>>> 
>>> 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.
>>> 
>spring mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spring

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 4 Aug 2014 08:55:06 +0200

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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 4 Aug 2014 08:44:22 +0000

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

s.

Sent from mobile

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

agreed ?

/hannes