Re: [Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence

Dhruv Dhody <dhruv.dhody@huawei.com> Tue, 03 November 2015 04:14 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB84B1B2CF5; Mon, 2 Nov 2015 20:14:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.809
X-Spam-Level:
X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] 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 tAUHiuHbYhX7; Mon, 2 Nov 2015 20:14:37 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3909A1B2CB4; Mon, 2 Nov 2015 20:14:35 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZV73422; Tue, 03 Nov 2015 04:14:31 +0000 (GMT)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 Nov 2015 04:14:29 +0000
Received: from BLREML509-MBX.china.huawei.com ([169.254.7.243]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Tue, 3 Nov 2015 09:44:23 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: Julien Meuric <julien.meuric@orange.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, Dhruv Dhody <dhruv.ietf@gmail.com>
Thread-Topic: Gen-art] Review: draft-ietf-pce-pcep-domain-sequence
Thread-Index: AQHREu+Uj/DDe9ySQUWUiRidhgiykJ6EK3aPgAMjKeCAATcM4IAABpCAgAEnd3A=
Date: Tue, 03 Nov 2015 04:14:23 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8C435982@BLREML509-MBX.china.huawei.com>
References: <5631337F.3050703@nostrum.com> <56320B67.9050309@nostrum.com> <56328BAB.2000208@joelhalpern.com> <CAB75xn5xsMsZBYWnGpBLn8nHz_5ttMJBkcjZZgC0uZzOBfPvBQ@mail.gmail.com> <56336308.2080504@joelhalpern.com> <56338E34.1000109@orange.com> <23CE718903A838468A8B325B80962F9B8C434C03@BLREML509-MBX.china.huawei.com> <563787DF.6070103@orange.com>
In-Reply-To: <563787DF.6070103@orange.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.194.186.138]
Content-Type: multipart/mixed; boundary="_002_23CE718903A838468A8B325B80962F9B8C435982BLREML509MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.563834A8.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.243, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 421e2e698a2decdddc474c407f17a2d7
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/QNzSvj5r_9O_PSl-nynlwDQISWc>
Cc: "draft-ietf-pce-pcep-domain-sequence.all@ietf.org" <draft-ietf-pce-pcep-domain-sequence.all@ietf.org>, General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 04:14:43 -0000

Hi Julien, All,

So now we have - (and thanks for bearing with me, as we get there...)

   IGP Area subobjects in the XRO are local to the current AS.  In case
   of multi-AS path computation to exclude an IGP area in a different
   AS, IGP Area subobject should be part of Explicit Exclusion Route
   Subobject (EXRS) in the IRO to specify the AS in which the IGP area
   is to be excluded.  Further policy may be applied to prune/ignore
   Area subobjects in XRO after "current AS" change during path
   computation.

I have also attached the diff of the working copy to show the GenArt and IANA review changes so far. 

Regards,
Dhruv

> -----Original Message-----
> From: Julien Meuric [mailto:julien.meuric@orange.com]
> Sent: 03 November 2015 00:57
> To: Dhruv Dhody; Joel Halpern Direct; Dhruv Dhody
> Cc: A. Jean Mahoney; General Area Review Team; draft-ietf-pce-pcep-
> domain-sequence.all@ietf.org
> Subject: Re: Gen-art] Review: draft-ietf-pce-pcep-domain-sequence
> 
> Hi,
> 
> How about adding a sentence reminding that "A" stands for "Autonomous"?
> E.g., "policies may apply at AS boundaries and Area IDs after AS change
> may be pruned/ignored."
> 
> Regard,
> 
> Julien
> 
> 
> Nov. 02, 2015 - dhruv.dhody@huawei.com:
> > Hi All,
> >
> > How is this -
> >
> >     IGP Area subobjects in the XRO are local to the current AS.  In
> case
> >     of multi-AS path computation to exclude an IGP area in a
> different
> >     AS, IGP Area subobject should be part of Explicit Exclusion Route
> >     Subobject (EXRS) in the IRO to specify the AS in which the IGP
> area
> >     is to be excluded.
> >
> > I have attached the working copy diff for easy reference.
> >
> > Regards,
> > Dhruv
> >
> >> -----Original Message-----
> >> From: Dhruv Dhody
> >> Sent: 02 November 2015 00:33
> >>
> >> Hi All,
> >>
> >> Sorry for delay in replying, let me try to send you proposed text
> >> tomorrow as per Julien's suggestion!
> >>
> >> Regards,
> >> Dhruv
> >>
> >>> -----Original Message-----
> >>> From: Julien Meuric [mailto:julien.meuric@orange.com]
> >>> Sent: 31 October 2015 00:35
> >>>
> >>> Hi Joel, hi Dhruv,
> >>>
> >>> Focusing on the Area ID issue, I'd support adding some text along
> >> with
> >>> Dhruv's proposal, but stricter (not just deferring to
> >>> "implementation's feeling"). I.e., Area IDs are AS-specific and
> >>> mustn't cross AS borders; AS-local Area IDs may be used inside an
> AS
> >>> (without restricting to the origin AS).
> >>>
> >>> See you in Yokohama,
> >>>
> >>> Julien
> >>>
> >>>
> >>> Oct. 30, 2015 - jmh.direct@joelhalpern.com:
> >>>>>           Given that Exclude Route Objects are not interleaved
> with
> >>>>>      include Objects, is there a restriction that Area IDs may
> >>>>> only
> >>> be
> >>>>>      excluded from paths within a single AS?
> >>>>>
> >>>>>
> >>>>> [Dhruv]: I guess this would depend on the PCE behavior during
> >>>>> inter-AS path computation i.e. PCEmay feel the area id
> subobjectis
> >>>>> irreleventand strips from the XRO before sending the request to
> >>>>> another PCE ​ or it might keep it intact.
> >>>>>
> >>>>>
> >>>>> This would be in s
> >>>>> ​pi​
> >>>>> ritof RFC 4874 where
> >>>>> ​-
> >>>>>
> >>>>>
> >>>>>
> >>>>> The number of subobjects to be avoided, specified in the
> >>>>>      signaled XRO, may be constant throughout the whole path
> >>>>> setup,
> >>> or the
> >>>>>      subobjects to be avoided may be removed from the XRO as they
> >>> become
> >>>>>      irrelevant in the subsequent hops of the path setup.
> >>>>>
> >>>>> We can always
> >>>>> ​use
> >>>>> EXRS in IRO specify the intentions much more clearly.
> >>>>>
> >>>>> If you agree, we can work on some text to add.
> >>>>
> >>>> I still can not see how the Excluded Route Object with an Area ID
> >>> will
> >>>> work.  How will a PCE which receives such a request know what AS
> it
> >>>> applies to?  It works fine if the whole path is within one AS.
> But
> >>> if
> >>>> this is a multi-AS request, the AS elements, if present at all,
> are
> >>> in
> >>>> the IRO.
> >>>> The most obvious approach would be to declare that the PCE shall
> >>>> assume that all Area ID exclusions apply to the origin AS.