Re: [OSPF] draft-psenak-ospf-segment-routing-extensions-05

"Acee Lindem (acee)" <acee@cisco.com> Tue, 22 September 2015 11:08 UTC

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26801A1BDD for <ospf@ietfa.amsl.com>; Tue, 22 Sep 2015 04:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 2U5NvYgmHjWD for <ospf@ietfa.amsl.com>; Tue, 22 Sep 2015 04:08:02 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845081A1BCB for <ospf@ietf.org>; Tue, 22 Sep 2015 04:08:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33219; q=dns/txt; s=iport; t=1442920080; x=1444129680; h=from:to:cc:subject:date:message-id:mime-version; bh=MXPf0T+EX3OLCvRdEN3SF3uW92ytePl5jaLIAq3y48U=; b=ivcFnFI8hX6OnsDhkwVBu0apN6Fq0BB+IcvyIzgxDvzqXGsZWavUUmk/ qSEhTigMoDAjMAGLbCRyASj8uVKyHJGME0bu104duibT9HIS+ZAaDiRGd e3HNXq1/pOORmqhkNiJG8xK7RsDtStj02oZesjmOTbQDrzd9ZTFUbRm5m M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DwAQDxNQFW/4wNJK1dgldNVGkGvU8BDYF8hXcCHIEmOBQBAQEBAQEBgQqEJAEBAQQjCjoSEgEIEQECAQEBIQcDAgQwFAMGCgQBDQWILg22b5QvAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLcIR8DQQGgmqBQwWIBoR3hUGDKQGFEId4gU6ENpEyg20fAQFCghEcgVRxAQGIZoEFAQEB
X-IronPort-AV: E=Sophos; i="5.17,572,1437436800"; d="scan'208,217"; a="29096234"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP; 22 Sep 2015 11:07:59 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t8MB7cSA002138 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Sep 2015 11:07:59 GMT
Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Sep 2015 06:07:51 -0500
Received: from xhc-rcd-x09.cisco.com (173.37.183.83) by xch-aln-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 22 Sep 2015 06:07:51 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.127]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0248.002; Tue, 22 Sep 2015 06:07:51 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>, "hannes@juniper.net" <hannes@juniper.net>, "rob.shakir@bt.com" <rob.shakir@bt.com>, "wim.henderickx@alcatel-lucent.com" <wim.henderickx@alcatel-lucent.com>, Jeff Tantsura <jeff.tantsura@ericsson.com>, "draft-psenak-ospf-segment-routing-extensions-05.all@ietf.org" <draft-psenak-ospf-segment-routing-extensions-05.all@ietf.org>
Thread-Topic: [OSPF] draft-psenak-ospf-segment-routing-extensions-05
Thread-Index: AQHQ9SbrpaNM3Eujo0OfqbM+4WfySg==
Date: Tue, 22 Sep 2015 11:07:51 +0000
Message-ID: <D226AE08.304BB%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.36.7.24]
Content-Type: multipart/alternative; boundary="_000_D226AE08304BBaceeciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/OZ6-MVKmV61hsC9LjCvuyliqcMs>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] draft-psenak-ospf-segment-routing-extensions-05
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2015 11:08:04 -0000

Hi Anil,
Since the setting of the flag being set indicates that the SID is local, L-Flag seems like a more appropriate moniker for this OSPF protocol flag.  Calling it the G flag will only result in confusion.
Thanks,
Acee

From: OSPF <ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org>> on behalf of "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com<mailto:anil.sn@huawei.com>>
Date: Tuesday, September 22, 2015 at 2:43 AM
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com<mailto:sprevidi@cisco.com>>, "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com<mailto:cfilsfil@cisco.com>>, "hannes@juniper.net<mailto:hannes@juniper.net>" <hannes@juniper.net<mailto:hannes@juniper.net>>, "rob.shakir@bt.com<mailto:rob.shakir@bt.com>" <rob.shakir@bt.com<mailto:rob.shakir@bt.com>>, Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx@alcatel-lucent.com>>, Jeff Tantsura <jeff.tantsura@ericsson.com<mailto:jeff.tantsura@ericsson.com>>, "draft-psenak-ospf-segment-routing-extensions-05.all@ietf.org<mailto:draft-psenak-ospf-segment-routing-extensions-05.all@ietf.org>" <draft-psenak-ospf-segment-routing-extensions-05.all@ietf.org<mailto:draft-psenak-ospf-segment-routing-extensions-05.all@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] draft-psenak-ospf-segment-routing-extensions-05

Hi Authors,

In Section : 24.2.  Prefix SID Sub-TLV, L-Flag represent IGP segment is local or global (Suggest to change to G so that it will be consistent with Segment Routing Architecture draft) similar to that can we have A-Flag to indicate Anycast SID.

The L-Flag: Local/Global Flag.  If set, then the value/index
         carried by the PrefixSID has local significance.  If not set,
         then the value/index carried by this subTLV has global
         significance.

https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-17
3.2<https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#section-3.2>.2>.  IGP Segment Terminology
3.2.1<https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#section-3.2.1>.1>.  IGP Segment, IGP SID
   The terms "IGP Segment" and "IGP SID" are the generic names for a
   segment attached to a piece of information advertised by a link-state
   IGP, e.g. an IGP prefix or an IGP adjacency.

   The IGP signaling extension to advertise an IGP segment includes the
   G-Flag indicating whether the IGP segment is global or local.
                                       IGP-SID
                                       +--+--+
                                      /   |   \
                             Prefix-SID   x   Adj-SID
                             +----+---+
                            /     |    \
                      Node-SID    y   Anycast-SID

                       Figure 7: IGP SID Terminology

   The IGP Segment terminology is introduced to ease the documentation
   of SR use-cases and hence does not propose a name for any possible
   variation of IGP segment supported by the architecture.  For example,
   y in Figure 7 could represent a local IGP segment attached to an IGP
   Prefix.  This variation, while supported by the SR architecture is
   not seen in the SR use-cases and hence does not receive a specific
   name.


Thanks & Regards
Anil S N

“Be liberal in what you accept, and conservative in what you send” - Jon Postel


From: Anil Kumar S N (VRP Network BL)
Sent: 21 September 2015 20:00
To: 'Peter Psenak'; 'sprevidi@cisco.com<mailto:'sprevidi@cisco.com>'; 'cfilsfil@cisco.com<mailto:'cfilsfil@cisco.com>'; 'hannes@juniper.net<mailto:'hannes@juniper.net>'; 'rob.shakir@bt.com<mailto:'rob.shakir@bt.com>'; 'wim.henderickx@alcatel-lucent.com<mailto:'wim.henderickx@alcatel-lucent.com>'; Jeff Tantsura
Cc: OSPF WG List
Subject: draft-psenak-ospf-segment-routing-extensions-05

Hi Authors,

In Segment Routing Architecture draft,  There is a provision to allocate multiple Adj-SIDs to same adjacency in case of bundle interface.
In IGP extension draft we need to have one more Adj-SID Sub-TLV type to distribute SID’s for bundle members with bundle member ID along with link type/data & ID.

Please let me know your opinion.

Reference :

https://tools.ietf.org/html/draft-ietf-spring-segment-routing-05

3.5.  IGP-Adjacency Segment, Adj-SID

A node MAY allocate multiple Adj-SIDs to the same adjacency.  An
   example is where the adjacency is established over a bundle
   interface.  Each bundle member MAY have its own Adj-SID.

Thanks & Regards
Anil S N

“Be liberal in what you accept, and conservative in what you send” - Jon Postel