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

"Acee Lindem (acee)" <acee@cisco.com> Fri, 01 August 2014 21:51 UTC

Return-Path: <acee@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C941A0107; Fri, 1 Aug 2014 14:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltiCNlWAx-bj; Fri, 1 Aug 2014 14:51:17 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2161A00DF; Fri, 1 Aug 2014 14:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7677; q=dns/txt; s=iport; t=1406929877; x=1408139477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sH9Stuo2hFi0ErFAvZsdUJi/2sQ/x8XJJ8biqJ2/kiI=; b=WBjj192Gk3JVYMkzVij8FRFLZdG42e1XBU3pE3713HLyzEn7JYhC/vCx v0Q9FZaogXGYgDm7ZkJb4zgXIuO9X9NsMUyPkH53xXWhJsPRnPXj1H74I rbVMYOclBC70Cq1epigpa62Xy/9vr+CzbHSl4qdW7kgBb5XHcJOQy3RfZ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiEFAKUK3FOtJV2d/2dsb2JhbABbgw1SVwTMBwyGd1MBgQsWd4QDAQEBBAEBATctBwsMBAIBCBEEAQEBHgkHJwsUCQgCBAENBYhCDchaF48ZMwcGhEUFl0+EK4FUkwaDSWyBRQ
X-IronPort-AV: E=Sophos;i="5.01,782,1400025600"; d="scan'208";a="65911095"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 01 Aug 2014 21:51:15 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s71LpGTC021319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 21:51:16 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 16:51:15 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, Chris Bowers <cbowers@juniper.net>
Thread-Topic: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02
Thread-Index: AQHPrdK3K92TJYOgt0uK26EtbeaoIg==
Date: Fri, 01 Aug 2014 21:51:14 +0000
Message-ID: <D00183F2.1745%acee@cisco.com>
References: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> <CFE267E5-A027-493B-A1C1-49BC66F59FB8@cisco.com> <ea683383e8654c519884fa0aead26d60@BLUPR05MB292.namprd05.prod.outlook.com> <FD404899-F5FE-472B-9D4F-AAAC5A95BF2F@cisco.com>
In-Reply-To: <FD404899-F5FE-472B-9D4F-AAAC5A95BF2F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.152.195]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9633890EEA765C43B10D903006E26AA6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/spring/X_YIYYDE2IcNTYQINTukZvVJjyQ
Cc: "spring@ietf.org" <spring@ietf.org>, Uma Chunduri <uma.chunduri@ericsson.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 21:51:20 -0000

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

On 8/1/14, 3:48 PM, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
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:sprevidi@cisco.com]
>> Sent: Friday, August 01, 2014 1:54 AM
>> To: Uma Chunduri
>> Cc: Chris Bowers; isis-wg@ietf.org; spring@ietf.org
>> 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:isis-wg-bounces@ietf.org] On Behalf Of Chris
>>> Bowers
>>> Sent: Thursday, July 31, 2014 2:42 PM
>>> To: isis-wg@ietf.org
>>> 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
>>> Isis-wg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>> 
>
>_______________________________________________
>spring mailing list
>spring@ietf.org
>https://www.ietf.org/mailman/listinfo/spring