From adrian@olddog.co.uk Tue Apr 3 03:25:05 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4027821F85B9 for ; Tue, 3 Apr 2012 03:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOj3MXEdU+dH for ; Tue, 3 Apr 2012 03:25:04 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5870621F85B8 for ; Tue, 3 Apr 2012 03:25:03 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q33AOcSf018024; Tue, 3 Apr 2012 11:24:40 +0100 Received: from 950129200 (AGrenoble-551-1-92-105.w92-150.abo.wanadoo.fr [92.150.203.105]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q33AOOWR017854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Apr 2012 11:24:25 +0100 From: "Adrian Farrel" To: "'Ramon Casellas'" , References: <0e5d01cd0df8$ebed2450$c3c76cf0$@olddog.co.uk> <0ABEE34E-BD75-44B9-BF04-B3A2D28635AE@cisco.com> <4F76CDFC.6010704@cttc.es> In-Reply-To: <4F76CDFC.6010704@cttc.es> Date: Tue, 3 Apr 2012 11:24:25 +0100 Message-ID: <06d201cd1183$f2ef00f0$d8cd02d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNVS10FqcgZrTCfzPFSh3PzZ4se6wGCxH3sAad32dKTXxHR0A== Content-Language: en-gb Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 10:25:05 -0000 Hello Ramon, >> I understand the motive for this work and, indeed, it fills a hole in = the protocol spec. > > [Ramon] if you could elaborate a bit more on which hole(s) exactly, I = would > make sure that we can come up with a more satisfactory proposal, e.g = a) the > lack of (some?) route sub-objects for domain encodings, b) the = ordering=20 > constraints, c) decoupling and relationship between PCE-sequences and=20 > domain-sequences? (personally, I find a) and b) more important.) I find a) most important. As far as I am concerned, the PCE sequence is already decoupled from the = IRO. I find the way that this I-D decouples the domain sequence from the path "inconvenient". =A0=20 >> I do hope that the authors are building it for shipping equipment and deployment. If >> not, would they please consider whether it should be experimental? > > [Ramon] I have no objection at being experimental, what option the WG = things more > appropriate is fine for me. Open issue for the chairs to drive. >> I am concerned that this document changes the definition and intent = contained in >> RFC 5440. In my opinion the authors of 5440, and the WG at the time, = went to >> some lengths to tie the content of objects in PCEP to the same = definitions found >> in RFCs 3209, 3473 and 3477. At the same time, definitions of = subobjects for path >> definition, should also pay attention to RFCs 4874 and 4920. The = intention is to not >> define more subobjects than needed and to keep registries aligned > > [Ramon] agreed, and this is the intention. See also my other comments = below Excellent. So it is probably just nits. > [Ramon] I would really appreciate your thoughts on whether=A0 = [E/X/R/I]RO=20 > sub-objects for OSPF-TE areas and IS-IS areas are needed, as well as = 4-byte > AS (unlike TLVs, 4 byte AS and 2-byte AS sub-objects cannot share the > encoding). This is in line with your concern whether more sub-objects = are > needed or not, which should also be brought to ccamp attention as = well. > > Some (initial, loose) discussions on the need for IGP sub-objects were > indirectly discussed in http://www.ietf.org/mail-archive/web/pce/current/msg02561.html We need to consider two "fringe" conditions. 1. A PCE serves multiple domains. In this case, if the PCC wishes to = control the domain path, it needs to be able to specify domain IDs as inclusions and exclusions. 2. There may be segments of the path where per-domain signaling is = needed. In this case there needs to be an exchange of objects (back and forth) = between PCEP and RSVP-TE in order to achieve control of the domain path. That said, in my experience, the domain paths in current deployments are = not long, and border routers are often known a priori. >> It is also worth noting how 4920=A0=A0handles 2 and 4 octet AS = numbers and that >> there is overlap in the definition of AS number subobjects with=20 >> draft-zhang-pce-hierarchy-extensions-01 > > [Ramon] We had considered 4920 for this, although the proposed = encodings > are as TLVs (for IF_ID ERROR_SPEC objects) and this i.-d. work was = (arguably) > regarding route objects. I agree that, as TLV encodings, a single 4 = byte encoding > for both 2-4 bytes AS makes a lot of sense, specially since the 16-bit sub-registry > is common. This would also solve the problems regarding IGP areas. > > If I may, what kind of encoding would you suggest? In previous = discussions it=20 > was suggested that we should use the IRO for the problem we were = trying to > solve , which somehow precludes the use of TLVs unless wrapped in a = ERO > subobject (had we been given the green light for a new object, which = is not > necessarily the right thing to do, I would be happy to use 4920 tlv = encodings > for this) I guess I would need to look at this in more detail. I don't see a lot = of difference between a TLV encoding and a subobject encoding. The main = difference is the codespace the T values come from. Obviously, you can't munge the = two code spaces, but you can share encodings. > [Ramon] AS number subobjects and all common IANA registry requests = between > this draft and draft-zhang-pce-hierarchy-extensions-01 MUST be unified = and being > involved in both we make sure they will. Perfect. =A0 >> In this light and on careful reading, the IANA section is somewhat = broken and >> confused about what should be in the registry it is creating. >=A0 > [Ramon] agreed, and most importantly, it must also be brought to ccamp > attention as well.=20 Good idea >> But I am also unsure why a new IRO type is needed. Surely the domain=20 >> sequence that is used in the computation is also the domain sequence=20 >> for the path that the LSP will take. This feeds on the points below. > > [Ramon] The main rationale behind this discriminator is the ordering > constraint, since (my guess) no ordering assumption could be inferred > from rfc5440. IIRC this was confirmed (I am sorry I wasn't in Taipei, = I > may be wrong). > Quoted from a past mail: > http://www.ietf.org/mail-archive/web/pce/current/msg02580.html > > "Unfortunately RFC5440 does not mention anything regarding sub-object > ordering, it only says "to specify that the computed path MUST = traverse=A0 > a set of specified network elements" and does not include some text in = > the spirit of "Objects within an IRO object MUST appear in the = resulting=20 > ERO in the same order that they appear in the IRO". Unless I am = mistaken, > this means that, at least in theory, we should not make assumptions > whether the sub-objects included in the IRO shall appear in the = resulting > ERO in the same relative ordering". As an RFC 5440 co-author=A0 maybe = you > can comment on this? is the ordering implicit? Very good quote. Yes, this uncovers the ordering issue with the IRO. = And, thinking back, it was exactly the intention that the IRO did not imply = any ordering. Usually, I think, the IRO would contain a small number of = nodes/links to give hints to the computation, or to take the path through key points = in the network. So, this is a bigger issue than just the domain sequence: how does the = PCC request an ordering of path elements? The answer may be that it should not need to. Maybe, even, that it has = no meaning for it to do so. This answer could apply equally to nodes, links, or domains. I think this can be proved by drawing a picture. If there is the = possibility to route a path from domain X through domains A, B, C, and D to domain Z, = why should the PCC state the order that they must be traversed? Surely the = PCE will work out which is the better path XABCDZ or XACBDZ. If, on the other = hand, the only possible path is XABCDZ then the PCC does not need to worry about = the order of the domains it lists in the IRO because the PCE can only produce one = result. Now, I can hear in my head the people saying that it is more complicated = if the PCE has to work out the ordering of the domains, but I wonder why this = is more complicated than working out the ordering of nodes. And I do think that = the PCC should be spared the complexity of knowing or working out any sequencing = for the path. > In any case, the actual solution and encoding is open to discussion. = IF > the ordering inclusion is implicit, I have no objection for using the > existing IRO and this includes your subsequent concerns with its = contents. > >> The algorithm in 3.4: >> - assumes only area IDs and AS numbers >> - assumes that a PCE knows at least one PCE responsible for >> each of=A0its neighboring domains =A0> > [Ramon] afaik, the algorithm was added recently in order to simplify = the > (apparently overkill and over-)specification of the IRO sub-objects = which > was also proposed by me in the aforementioned mail=20 > web/pce/current/msg02580.html (which tried, as a informational = exercise, > to also capture intra-domain objects). The motivation behind both is = to > clarify its usage. Depending on the outcomes of this and further = discussions > they can be elaborated, removed (by relying on the existing documents) = or > clarified. OK >> I would like the authors to take care that the identity of a boundary = node >> does not uniquely identify a next-hop domain (even if it may be >> successfully used for domain routing given the knowledge of the next >> domain, next boundary node, or egress node) and the text should not >> imply that it does. This is hidden at the end of 3.4 some time after = the=A0=A0 >> boundary node/link discussion. > > [Ramon] point taken. we will review the text accordingly. > >> Shouldn't you allow "loose" hops in the domain path? (i.e. gaps = between >> domains). > > I don't see any special reason why we shouldn't, although one concern = I=20 > have is how would this relate to RFC5440 statement "The L bit of such > sub-object has no meaning within an IRO"? Ah, my bad. As above, the original (type 1) IRO has no ordering or = tightness of sequencing. Thus, it is just a list of things to include. =A0 *if* you stay with the type 2 IRO, and *if* you define ordering in the = type 2 IRO (as currently written), then you need to consider the L bit. >> Can I also mix other concepts with the domain path? What about a = consistent >> lambda, or a core node that needs to be on the path? > > [Ramon] IMHO, there are two (decoupled) points here: > > a) whether the current IRO has ordering constraints or not > > b) If a new IRO is needed whether only domain-related info is = conveyed. > > An (authoritative ;-) ) answer for a) would be much appreciated. Ask JP ;-) My reading agrees with yours (and my memory) as above. The IRO is just a = set of objects to be included. Presenting the elements of the set in any order = will have the same result (plus or minus ECMP situations and peculiarities of specific PCE implementations). > There was also the concern of separating the roles of intra-domain = path > computation IRO and the resolution of PCEs in a collaborative setting. = I'm not entirely sure I get this point. A PCE can only compute a path = segment that goes through its domain of responsibility - it will find all = elements in the IRO that it recognises as "local" and include them in the segment it = makes, and it will pass on all other elements to the other PCEs it cooperates = with. There is clearly a task for the "aggregating PCE" (which may be the head = of the chain, or may be the parent) to put the segments together according to = the complete IRO. > For b), if we agree on the idea "the new object type imposes > ordering constraints" I would not be against being like any other > IRO. With a new IRO type we can be more concrete regarding the > role of the must-process p-bit, what to do with unknown objects=20 > (locally to a PCE) i.e., nothing is said in IRO and XRO objects what > the procedures are when a sub-object is "not found" (in the TED?). This seems to cut to a complexity question. We could allow a PCC to specify as much or as little of the information = about the path as it likes. This is certainly fully flexible, but it seems to = me to masively over-complicate the protocol and the functional model. Isn't it = the case that the PCE is capable of selecting the *best* path. Thus, for = example, there is no need for the PCC to say "I want a continuous lambda for the = segment over domain X" because that implies the PCC knows stuff about domain X = that the PCE is unaware of. > From the mail: "it is not clear to me what should be the default > procedure for an unkonwn IRO subobject. It could be ignored or > it could trigger an error. If we apply this to the domain sequence, > I would say that an unknown subobject at this level should trigger > some kind of high level error, like "PCE domain chain broken" or > similar" That is a good question, and there are two sub-species of "unknown". The processing collapses to the same behavior, but it is worth looking at = them separately. 1. I know the T value, but I can't find the identified resource 2. I don't know the T value. In the first case, the PCE processes the IRO to include as many of the = elements of the IRO as possible. If the PCE is passing the request onwards, it is = OK for it to fail to find the resource, and it can assume that the next PCE = might be able to satisfy the remaining elements of the IRO. On the other hand, if = the PCE is making an end-to-end (or edge-to-edge, or end-to-edge) path and will = return the response to a PCC (rather than pass it on) then the PCE must fail if = it cannot satisfy the IRO (this failure behavior is in RFC 5440). Now, I would hold that the second case can be handled identically to the = first case. And ultimately, when the path segments are aggregated by a head-end PCE = or by a parent PCE, that PCE can check to see whether any elements of the IRO = are still missing.=20 There is, just one wrinkle in that case which is that the aggregating = PCE must understand all of the T values, or the IRO must be stripped and returned = on the response messages. >> In 3.5.7 I don't see that the domain sequence is necessarily an = alternative >> to the PCE sequence. There are cases where even with a domain = sequence, >> a PCE sequence is important. > > [Ramon] Personally, (although we still need to discuss it more) I = don't see > domain-sequence and pce-sequence as exclusive and I agree they can > coexist. The whole 3.5.7 needs to be revisted, including J.P. comments > during the meeting that some assertions were false (which is true, = brpc > may benefit from a domain sequence but does not require it) Agrred >> Section 5 will need loads of work because the domain sequence (even >> for inclusion, not reporting) provides information valuable to an = attacker. > >[Ramon] agreed. > > Thanks again, > Ramon Very welcome. Most fun I have had all year :-) Adrian From helia.pouyllau@alcatel-lucent.com Tue Apr 3 12:25:31 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B07E11E81A7 for ; Tue, 3 Apr 2012 12:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GuI2tEtV+ZF for ; Tue, 3 Apr 2012 12:25:30 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 17D3F11E81A6 for ; Tue, 3 Apr 2012 12:25:29 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q33JPQ19010285 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Apr 2012 21:25:26 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 3 Apr 2012 21:25:26 +0200 From: "POUYLLAU, HELIA (HELIA)" To: JP Vasseur , "pce@ietf.org" Date: Tue, 3 Apr 2012 21:25:25 +0200 Thread-Topic: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Thread-Index: AQHNDcj5BytZrSKoxkODXQZ+UPe2w5aBgElQgAgCnQA= Message-ID: <2D26984ED849C94A8C7D6276DA008FF2142CD99856@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <7AEB3D6833318045B4AE71C2C87E8E1720C8FADE@dfweml511-mbx.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1720C8FADE@dfweml511-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 19:25:31 -0000 Support (as co-author ^^) Btw, default values are indicated (sorry that I did not have that in mind d= uring the meeting) but it solely appear in the text and could be emphasized Regards Helia -----Message d'origine----- De=A0: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] De la part de Lee= young Envoy=E9=A0: jeudi 29 mars 2012 19:05 =C0=A0: JP Vasseur; pce@ietf.org Objet=A0: Re: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Support - With specifying the default value for new TLV's defined Young -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Va= sseur Sent: Thursday, March 29, 2012 11:28 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt Dear all, We had a pretty strong support for adopting draft-pouyllau-pce-enhanced-err= ors a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-= pouyllau-pce-enhanced-errors as a PCE WG Document ? Thanks. JP and Julien. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From udayasree.palle@huawei.com Tue Apr 3 22:28:01 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C8D21F8692 for ; Tue, 3 Apr 2012 22:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRBIoyNph18P for ; Tue, 3 Apr 2012 22:28:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1BF21F84FB for ; Tue, 3 Apr 2012 22:28:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEY09821; Wed, 04 Apr 2012 01:27:59 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Apr 2012 22:25:30 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Apr 2012 22:25:28 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.30]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Wed, 4 Apr 2012 13:25:23 +0800 From: Udayasree palle To: "pce@ietf.org" Thread-Topic: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Thread-Index: AQHNDdGvNqFCu485aEq7rpfD7V6GlZaKKstt Date: Wed, 4 Apr 2012 05:26:15 +0000 Message-ID: References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> <4F7490C1.5030500@cttc.es>, <006701cd0dce$26131020$72393060$@dhody@huawei.com> In-Reply-To: <006701cd0dce$26131020$72393060$@dhody@huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.96.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 05:28:01 -0000 Support (as a Co-Author) Regards, Udaya ________________________________________ From: pce-bounces@ietf.org [pce-bounces@ietf.org] on behalf of Dhruv Dhody = [dhruv.dhody@huawei.com] Sent: Thursday, March 29, 2012 10:35 PM To: 'Ramon Casellas'; pce@ietf.org Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a ne= w PCE WG Support (Co-author :)) One IPR has been disclosed. (https://datatracker.ietf.org/ipr/1690/) As per my knowledge no other IPR exist. Regards, Dhruv -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ramon Casellas Sent: Thursday, March 29, 2012 6:42 PM To: pce@ietf.org Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a ne= w PCE WG On 03/29/2012 06:29 PM, JP Vasseur wrote: > > Could you please let us know if you are in favor/opposed to adopting > draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? > Yes / support (as a co-author) R. PS: There is an IPR disclosure https://datatracker.ietf.org/ipr/1690/ covering this draft. I am not aware of other IPRs _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce= From dhruv.dhody@huawei.com Wed Apr 4 04:56:16 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC27E21F86CF for ; Wed, 4 Apr 2012 04:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q9NmOaHYMqE for ; Wed, 4 Apr 2012 04:56:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 81FBC21F86CE for ; Wed, 4 Apr 2012 04:56:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEQ28911; Wed, 04 Apr 2012 07:56:08 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 04:47:22 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 04:47:20 -0700 Received: from blrprnc03ns (10.18.96.92) by szxeml415-hub.china.huawei.com (10.82.67.154) with Microsoft SMTP Server id 14.1.323.3; Wed, 4 Apr 2012 19:47:11 +0800 From: Dhruv Dhody To: , 'Ramon Casellas' , References: <0e5d01cd0df8$ebed2450$c3c76cf0$@olddog.co.uk> <0ABEE34E-BD75-44B9-BF04-B3A2D28635AE@cisco.com> <4F76CDFC.6010704@cttc.es> <06d201cd1183$f2ef00f0$d8cd02d0$@olddog.co.uk> In-Reply-To: <06d201cd1183$f2ef00f0$d8cd02d0$@olddog.co.uk> Date: Wed, 4 Apr 2012 17:17:10 +0530 Organization: HTIPL Message-ID: <077601cd1258$ac06ef10$0414cd30$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0777_01CD1286.C5BF2B10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQNVS10FqcgZrTCfzPFSh3PzZ4se6wGCxH3sAad32dKTXxHR0IABrYbg Content-Language: en-us X-Originating-IP: [10.18.96.92] X-CFilter-Loop: Reflected Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhruv.dhody@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 11:56:16 -0000 ------=_NextPart_000_0777_01CD1286.C5BF2B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Adrian, Please find the comments inline.. Dear WG Chairs, Once the WG has made the decision on the adoption, we can re-poll the WG and get consensus on the issue of encoding domain-sequence. Authors do have a preference but we are completely open for what the WG consensus dictates and revise the document accordingly. Regards, Dhruv >-----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Adrian > Farrel > Sent: Tuesday, April 03, 2012 3:54 PM > To: 'Ramon Casellas'; pce@ietf.org > Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new > PCE WG > > Hello Ramon, > > >> I understand the motive for this work and, indeed, it fills a hole in the > protocol spec. > > > > [Ramon] if you could elaborate a bit more on which hole(s) exactly, I would > > make sure that we can come up with a more satisfactory proposal, e.g a) the > > lack of (some?) route sub-objects for domain encodings, b) the ordering > > constraints, c) decoupling and relationship between PCE-sequences and > > domain-sequences? (personally, I find a) and b) more important.) > > I find a) most important. > As far as I am concerned, the PCE sequence is already decoupled from the IRO. > I find the way that this I-D decouples the domain sequence from the path > "inconvenient". > [Dhruv Dhody>] We feel the decoupling allow us to handle IRO better. As PCE is used in multiple situations, use of new type IRO for encoding domain sequence kept the meaning of IRO but allowed us to define better rules. We can poll again to get a rough consensus on this. > >> I do hope that the authors are building it for shipping equipment and > deployment. If > >> not, would they please consider whether it should be experimental? > > > > [Ramon] I have no objection at being experimental, what option the WG > things > more > > appropriate is fine for me. > > Open issue for the chairs to drive. > > >> I am concerned that this document changes the definition and intent > contained > in > >> RFC 5440. In my opinion the authors of 5440, and the WG at the time, went > to > >> some lengths to tie the content of objects in PCEP to the same definitions > found > >> in RFCs 3209, 3473 and 3477. At the same time, definitions of subobjects > for > path > >> definition, should also pay attention to RFCs 4874 and 4920. The intention > is > to not > >> define more subobjects than needed and to keep registries aligned > > > > [Ramon] agreed, and this is the intention. See also my other comments below > > Excellent. So it is probably just nits. > > > [Ramon] I would really appreciate your thoughts on whether [E/X/R/I]RO > > sub-objects for OSPF-TE areas and IS-IS areas are needed, as well as 4-byte > > AS (unlike TLVs, 4 byte AS and 2-byte AS sub-objects cannot share the > > encoding). This is in line with your concern whether more sub-objects are > > needed or not, which should also be brought to ccamp attention as well. > > > > Some (initial, loose) discussions on the need for IGP sub-objects were > > indirectly discussed in > http://www.ietf.org/mail-archive/web/pce/current/msg02561.html > > We need to consider two "fringe" conditions. > > 1. A PCE serves multiple domains. In this case, if the PCC wishes to control > the > domain path, it needs to be able to specify domain IDs as inclusions and > exclusions. > > 2. There may be segments of the path where per-domain signaling is needed. In > this case there needs to be an exchange of objects (back and forth) between > PCEP > and RSVP-TE in order to achieve control of the domain path. > > That said, in my experience, the domain paths in current deployments are not > long, and border routers are often known a priori. > [Dhruv Dhody>] 1. PCE serving multiple domains is easily handled in the domain-sequence where a PCE is well aware that it can handle one or more domains in the sequence. We can further check allowing Explicit Exclusion Route subobject (EXRS) in the domain-sequence. 2. In case of per-domain signaling with loose path, we see little use of domain-sequence, this could be explicitly mentioned in the document. > >> It is also worth noting how 4920 handles 2 and 4 octet AS numbers and > that > >> there is overlap in the definition of AS number subobjects with > >> draft-zhang-pce-hierarchy-extensions-01 > > > > [Ramon] We had considered 4920 for this, although the proposed encodings > > are as TLVs (for IF_ID ERROR_SPEC objects) and this i.-d. work was > (arguably) > > regarding route objects. I agree that, as TLV encodings, a single 4 byte > encoding > > for both 2-4 bytes AS makes a lot of sense, specially since the 16-bit > sub-registry > > is common. This would also solve the problems regarding IGP areas. > > > > If I may, what kind of encoding would you suggest? In previous discussions > it > > was suggested that we should use the IRO for the problem we were trying to > > solve , which somehow precludes the use of TLVs unless wrapped in a ERO > > subobject (had we been given the green light for a new object, which is not > > necessarily the right thing to do, I would be happy to use 4920 tlv > encodings > > for this) > > I guess I would need to look at this in more detail. I don't see a lot of > difference between a TLV encoding and a subobject encoding. The main > difference > is the codespace the T values come from. Obviously, you can't munge the two > code > spaces, but you can share encodings. [Dhruv Dhody>] We all agree that new subobjects are needed, as far the encoding of those subobjects its important for us to keep it aligned to the definition of other subobjects, as per general subobjects definition: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ |L| Type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ We did follow this guidelines, where as the TLV require following encoding which would be incompatible with subobjects encoding: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > [Ramon] AS number subobjects and all common IANA registry requests between > > this draft and draft-zhang-pce-hierarchy-extensions-01 MUST be unified and > being > > involved in both we make sure they will. > > Perfect. > > >> In this light and on careful reading, the IANA section is somewhat broken > and > >> confused about what should be in the registry it is creating. > > > > [Ramon] agreed, and most importantly, it must also be brought to ccamp > > attention as well. > > Good idea > > >> But I am also unsure why a new IRO type is needed. Surely the domain > >> sequence that is used in the computation is also the domain sequence > >> for the path that the LSP will take. This feeds on the points below. > > > > [Ramon] The main rationale behind this discriminator is the ordering > > constraint, since (my guess) no ordering assumption could be inferred > > from rfc5440. IIRC this was confirmed (I am sorry I wasn't in Taipei, I > > may be wrong). > > Quoted from a past mail: > > http://www.ietf.org/mail-archive/web/pce/current/msg02580.html > > > > "Unfortunately RFC5440 does not mention anything regarding sub-object > > ordering, it only says "to specify that the computed path MUST traverse > > a set of specified network elements" and does not include some text in > > the spirit of "Objects within an IRO object MUST appear in the resulting > > ERO in the same order that they appear in the IRO". Unless I am mistaken, > > this means that, at least in theory, we should not make assumptions > > whether the sub-objects included in the IRO shall appear in the resulting > > ERO in the same relative ordering". As an RFC 5440 co-author maybe you > > can comment on this? is the ordering implicit? > > Very good quote. Yes, this uncovers the ordering issue with the IRO. And, > thinking back, it was exactly the intention that the IRO did not imply any > ordering. Usually, I think, the IRO would contain a small number of > nodes/links > to give hints to the computation, or to take the path through key points in > the > network. > > So, this is a bigger issue than just the domain sequence: how does the PCC > request an ordering of path elements? > > The answer may be that it should not need to. Maybe, even, that it has no > meaning for it to do so. > This answer could apply equally to nodes, links, or domains. > > I think this can be proved by drawing a picture. If there is the possibility > to > route a path from domain X through domains A, B, C, and D to domain Z, why > should the PCC state the order that they must be traversed? Surely the PCE > will > work out which is the better path XABCDZ or XACBDZ. If, on the other hand, > the > only possible path is XABCDZ then the PCC does not need to worry about the > order > of the domains it lists in the IRO because the PCE can only produce one > result. > > Now, I can hear in my head the people saying that it is more complicated if > the > PCE has to work out the ordering of the domains, but I wonder why this is > more > complicated than working out the ordering of nodes. And I do think that the > PCC > should be spared the complexity of knowing or working out any sequencing for > the > path. [Dhruv Dhody>] Domain sequence would either be pre configured or computed by some other means (eg. HPCE). Incase of HPCE, Parent PCE can determine the correct order and specify the order as its usually done in ERO; incase of admin has configured it at PCC, IMHO admin is well aware of the sequence (it is a sequence afterall). I am aware of some implementation of CSPF that requires ordering esp in case of strict hops. So I do believe in my opinion the complexity of PCE to figure out domains on its own is high. Also consider P2MP where if the order is not considered the complexity of the algorithm at PCE will only increase. > > In any case, the actual solution and encoding is open to discussion. IF > > the ordering inclusion is implicit, I have no objection for using the > > existing IRO and this includes your subsequent concerns with its contents. > > > >> The algorithm in 3.4: > >> - assumes only area IDs and AS numbers > >> - assumes that a PCE knows at least one PCE responsible for > >> each of its neighboring domains > > > > [Ramon] afaik, the algorithm was added recently in order to simplify the > > (apparently overkill and over-)specification of the IRO sub-objects which > > was also proposed by me in the aforementioned mail > > web/pce/current/msg02580.html (which tried, as a informational exercise, > > to also capture intra-domain objects). The motivation behind both is to > > clarify its usage. Depending on the outcomes of this and further > discussions > > they can be elaborated, removed (by relying on the existing documents) or > > clarified. > > OK > > >> I would like the authors to take care that the identity of a boundary node > >> does not uniquely identify a next-hop domain (even if it may be > >> successfully used for domain routing given the knowledge of the next > >> domain, next boundary node, or egress node) and the text should not > >> imply that it does. This is hidden at the end of 3.4 some time after the > >> boundary node/link discussion. > > > > [Ramon] point taken. we will review the text accordingly. > > > >> Shouldn't you allow "loose" hops in the domain path? (i.e. gaps between > >> domains). > > > > I don't see any special reason why we shouldn't, although one concern I > > have is how would this relate to RFC5440 statement "The L bit of such > > sub-object has no meaning within an IRO"? > > Ah, my bad. As above, the original (type 1) IRO has no ordering or tightness > of > sequencing. Thus, it is just a list of things to include. > > *if* you stay with the type 2 IRO, and *if* you define ordering in the type 2 > IRO (as currently written), then you need to consider the L bit. > [Dhruv Dhody>] Yes we will! > >> Can I also mix other concepts with the domain path? What about a > consistent > >> lambda, or a core node that needs to be on the path? > > > > [Ramon] IMHO, there are two (decoupled) points here: > > > > a) whether the current IRO has ordering constraints or not > > > > b) If a new IRO is needed whether only domain-related info is conveyed. > > > > An (authoritative ;-) ) answer for a) would be much appreciated. > > Ask JP ;-) > > My reading agrees with yours (and my memory) as above. The IRO is just a set > of > objects to be included. Presenting the elements of the set in any order will > have the same result (plus or minus ECMP situations and peculiarities of > specific PCE implementations). > > > There was also the concern of separating the roles of intra-domain path > > computation IRO and the resolution of PCEs in a collaborative setting. > > I'm not entirely sure I get this point. A PCE can only compute a path segment > that goes through its domain of responsibility - it will find all elements in > the IRO that it recognises as "local" and include them in the segment it > makes, > and it will pass on all other elements to the other PCEs it cooperates with. > There is clearly a task for the "aggregating PCE" (which may be the head of > the > chain, or may be the parent) to put the segments together according to the > complete IRO. [Dhruv Dhody>] In case of BRPC where the computation starts from the PCE(n); domain-sequence serves the important purpose of reaching domain(n); if a PCE has to go through IRO which has intra-domain segments (node, links) plus the information on domain-sequence, it gets bit complicated to handle. We specify clear separation for the very same reason. We can provide suggested handling when both IRO of type 1 and 2 exist. > > > For b), if we agree on the idea "the new object type imposes > > ordering constraints" I would not be against being like any other > > IRO. With a new IRO type we can be more concrete regarding the > > role of the must-process p-bit, what to do with unknown objects > > (locally to a PCE) i.e., nothing is said in IRO and XRO objects what > > the procedures are when a sub-object is "not found" (in the TED?). > > This seems to cut to a complexity question. > We could allow a PCC to specify as much or as little of the information about > the path as it likes. This is certainly fully flexible, but it seems to me to > masively over-complicate the protocol and the functional model. Isn't it the > case that the PCE is capable of selecting the *best* path. Thus, for example, > there is no need for the PCC to say "I want a continuous lambda for the > segment > over domain X" because that implies the PCC knows stuff about domain X that > the > PCE is unaware of. [Dhruv Dhody>] Domain-sequence is made of domains(AS and area) and *optional* Boundary information (ABR, ASBR, inter-as links). All this information is known to the admin as thus configured at PCC or learned via parent PCE. I don't think there is any information here that only PCC is aware of where as PCE is not. Also PCC can continue to specify as little information and continue to use the existing mechanims. > > > From the mail: "it is not clear to me what should be the default > > procedure for an unkonwn IRO subobject. It could be ignored or > > it could trigger an error. If we apply this to the domain sequence, > > I would say that an unknown subobject at this level should trigger > > some kind of high level error, like "PCE domain chain broken" or > > similar" > > That is a good question, and there are two sub-species of "unknown". The > processing collapses to the same behavior, but it is worth looking at them > separately. > > 1. I know the T value, but I can't find the identified resource > 2. I don't know the T value. > > In the first case, the PCE processes the IRO to include as many of the > elements > of the IRO as possible. If the PCE is passing the request onwards, it is OK > for > it to fail to find the resource, and it can assume that the next PCE might be > able to satisfy the remaining elements of the IRO. On the other hand, if the > PCE > is making an end-to-end (or edge-to-edge, or end-to-edge) path and will > return > the response to a PCC (rather than pass it on) then the PCE must fail if it > cannot satisfy the IRO (this failure behavior is in RFC 5440). > > Now, I would hold that the second case can be handled identically to the > first > case. > > And ultimately, when the path segments are aggregated by a head-end PCE or by > a > parent PCE, that PCE can check to see whether any elements of the IRO are > still > missing. > > There is, just one wrinkle in that case which is that the aggregating PCE > must > understand all of the T values, or the IRO must be stripped and returned on > the > response messages. > [Dhruv Dhody>] At a time when we are considering enhance error and notification handling [draft-pouyllau-pce-enhanced-errors], its important that our inter-domain mechanism specify errors correctly and propagate them to the PCC. In this document we made a humble attempt to specify the scope of the IRO and clear error handling. > >> In 3.5.7 I don't see that the domain sequence is necessarily an > alternative > >> to the PCE sequence. There are cases where even with a domain sequence, > >> a PCE sequence is important. > > > > [Ramon] Personally, (although we still need to discuss it more) I don't see > > domain-sequence and pce-sequence as exclusive and I agree they can > > coexist. The whole 3.5.7 needs to be revisted, including J.P. comments > > during the meeting that some assertions were false (which is true, brpc > > may benefit from a domain sequence but does not require it) > > Agrred > > >> Section 5 will need loads of work because the domain sequence (even > >> for inclusion, not reporting) provides information valuable to an > attacker. > > > >[Ramon] agreed. > > > > Thanks again, > > Ramon > > Very welcome. > Most fun I have had all year :-) > > Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0777_01CD1286.C5BF2B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a = new PCE WG

Dear = Adrian,

Please find = the comments inline..

Dear WG = Chairs,

Once the WG = has made the decision on the adoption, we can re-poll = the WG and = get consensus on the issue of encoding domain-sequence. Authors do have a preference = but we are completely open for what the WG consensus = dictates = and revise the document accordingly.     

Regards,

Dhruv


>-----Original Message-----

> From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Adrian

> Farrel

> Sent: Tuesday, April 03, 2012 3:54 PM

> To: 'Ramon Casellas'; pce@ietf.org

> Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 = as a new

> PCE WG

> =

> Hello Ramon,

> =

> >> I understand the motive for this work and, indeed, it = fills a hole in the

> protocol spec.

> >

> > [Ramon] if you could elaborate a bit more on which hole(s) = exactly, I would

> > make sure that we can come up with a more satisfactory = proposal, e.g a) the

> > lack of (some?) route sub-objects for domain encodings, b) the = ordering

> > constraints, c) decoupling and relationship between = PCE-sequences and

> > domain-sequences? (personally, I find a) and b) more = important.)

> =

> I find a) most important.

> As far as I am concerned, the PCE sequence is already decoupled = from the IRO.

> I find the way that this I-D decouples the domain sequence from the = path

> "inconvenient".

>

[Dhruv Dhody>] We feel the decoupling allow us = to handle IRO better. As PCE is used in multiple situations, use of new = type IRO for encoding domain sequence kept the meaning of IRO but = allowed = us to define better rules. We can poll again to = get a rough consensus on = this.

 

> >> I do hope that the authors are building it for shipping = equipment and

> deployment. If

> >> not, would they please consider whether it should be = experimental?

> >

> > [Ramon] I have no objection at being experimental, what option = the WG

> things

> more

> > appropriate is fine for me.

> =

> Open issue for the chairs to drive.

> =

> >> I am concerned that this document changes the definition = and intent

> contained

> in

> >> RFC 5440. In my opinion the authors of 5440, and the WG at = the time, went

> to

> >> some lengths to tie the content of objects in PCEP to the = same definitions

> found

> >> in RFCs 3209, 3473 and 3477. At the same time, definitions = of subobjects

> for

> path

> >> definition, should also pay attention to RFCs 4874 and = 4920. The intention

> is

> to not

> >> define more subobjects than needed and to keep registries = aligned

> >

> > [Ramon] agreed, and this is the intention. See also my other = comments below

> =

> Excellent. So it is probably just nits.

> =

> > [Ramon] I would really appreciate your thoughts on = whether  [E/X/R/I]RO

> > sub-objects for OSPF-TE areas and IS-IS areas are needed, as = well as 4-byte

> > AS (unlike TLVs, 4 byte AS and 2-byte AS sub-objects cannot = share the

> > encoding). This is in line with your concern whether more = sub-objects are

> > needed or not, which should also be brought to ccamp attention = as well.

> >

> > Some (initial, loose) discussions on the need for IGP = sub-objects were

> > indirectly discussed in

> <= SPAN LANG=3D"en-us">http://www.ietf.org/mail-archive/web/pce/current/msg02561.html

> =

> We need to consider two "fringe" = conditions.

> =

> 1. A PCE serves multiple domains. In this case, if the PCC wishes = to control

> the

> domain path, it needs to be able to specify domain IDs as = inclusions and

> exclusions.

> =

> 2. There may be segments of the path where per-domain signaling is = needed. In

> this case there needs to be an exchange of objects (back and forth) = between

> PCEP

> and RSVP-TE in order to achieve control of the domain = path.

> =

> That said, in my experience, the domain paths in current = deployments are not

> long, and border routers are often known a = priori.

>

[Dhruv Dhody>]

1. PCE serving multiple domains is easily handled = in the domain-sequence where a PCE is well aware that it can handle one = or more domains in the sequence. We can further check allowing Explicit = Exclusion Route subobject (EXRS) in the domain-sequence. =

2. In case of per-domain signaling with loose path, = we see little use of domain-sequence, this could be explicitly mentioned = in the document. 

> >> It is also worth noting how 4920  handles 2 and = 4 octet AS numbers and

> that

> >> there is overlap in the definition of AS number subobjects = with

> >> draft-zhang-pce-hierarchy-extensions-01

> >

> > [Ramon] We had considered 4920 for this, although the proposed = encodings

> > are as TLVs (for IF_ID ERROR_SPEC objects) and this i.-d. work = was

> (arguably)

> > regarding route objects. I agree that, as TLV encodings, a = single 4 byte

> encoding

> > for both 2-4 bytes AS makes a lot of sense, specially since = the 16-bit

> sub-registry

> > is common. This would also solve the problems regarding IGP = areas.

> >

> > If I may, what kind of encoding would you suggest? In previous = discussions

> it

> > was suggested that we should use the IRO for the problem we = were trying to

> > solve , which somehow precludes the use of TLVs unless wrapped = in a ERO

> > subobject (had we been given the green light for a new object, = which is not

> > necessarily the right thing to do, I would be happy to use = 4920 tlv

> encodings

> > for this)

> =

> I guess I would need to look at this in more detail. I don't see a = lot of

> difference between a TLV encoding and a subobject encoding. The = main

> difference

> is the codespace the T values come from. Obviously, you can't munge = the two

> code

> spaces, but you can share encodings.

[Dhruv Dhody>] We all agree = that new subobjects are = needed, as far = the encoding of those = subobjects its important for us to keep it = aligned to the definition of other = subobjects, as = per general subobjects definition:  

    0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+<= /SPAN>

   |L|    Type     = |     Length    | (Subobject = contents)          = |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+<= /SPAN>

We did = follow this guidelines, = where as the TLV require following encoding which = would be incompatible with subobjects = encoding:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>

   = |            =   = Type           &nb= sp; = |            = = Length            = |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>

   = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |

   = ~            =             &= nbsp;    = Value           &n= bsp;           &nb= sp;     ~

   = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>

 

> =

> > [Ramon] AS number subobjects and all common IANA registry = requests between

> > this draft and draft-zhang-pce-hierarchy-extensions-01 MUST be = unified and

> being

> > involved in both we make sure they will.

> =

> Perfect.

> =

> >> In this light and on careful reading, the IANA section is = somewhat broken

> and

> >> confused about what should be in the registry it is = creating.

> >

> > [Ramon] agreed, and most importantly, it must also be brought = to ccamp

> > attention as well.

> =

> Good idea

> =

> >> But I am also unsure why a new IRO type is needed. Surely = the domain

> >> sequence that is used in the computation is also the = domain sequence

> >> for the path that the LSP will take. This feeds on the = points below.

> >

> > [Ramon] The main rationale behind this discriminator is the = ordering

> > constraint, since (my guess) no ordering assumption could be = inferred

> > from rfc5440. IIRC this was confirmed (I am sorry I wasn't in = Taipei, I

> > may be wrong).

> > Quoted from a past mail:

> > <= SPAN LANG=3D"en-us">http://www.ietf.org/mail-archive/web/pce/current/msg02580.html

> >

> > "Unfortunately RFC5440 does not mention anything = regarding sub-object

> > ordering, it only says "to specify that the computed path = MUST traverse

> > a set of specified network elements" and does not include = some text in

> > the spirit of "Objects within an IRO object MUST appear = in the resulting

> > ERO in the same order that they appear in the IRO". = Unless I am mistaken,

> > this means that, at least in theory, we should not make = assumptions

> > whether the sub-objects included in the IRO shall appear in = the resulting

> > ERO in the same relative ordering". As an RFC 5440 = co-author  maybe you

> > can comment on this? is the ordering = implicit?

> =

> Very good quote. Yes, this uncovers the ordering issue with the = IRO. And,

> thinking back, it was exactly the intention that the IRO did not = imply any

> ordering. Usually, I think, the IRO would contain a small number = of

> nodes/links

> to give hints to the computation, or to take the path through key = points in

> the

> network.

> =

> So, this is a bigger issue than just the domain sequence: how does = the PCC

> request an ordering of path elements?

> =

> The answer may be that it should not need to. Maybe, even, that it = has no

> meaning for it to do so.

> This answer could apply equally to nodes, links, or = domains.

> =

> I think this can be proved by drawing a picture. If there is the = possibility

> to

> route a path from domain X through domains A, B, C, and D to domain = Z, why

> should the PCC state the order that they must be traversed? Surely = the PCE

> will

> work out which is the better path XABCDZ or XACBDZ. If, on the = other hand,

> the

> only possible path is XABCDZ then the PCC does not need to worry = about the

> order

> of the domains it lists in the IRO because the PCE can only produce = one

> result.

> =

> Now, I can hear in my head the people saying that it is more = complicated if

> the

> PCE has to work out the ordering of the domains, but I wonder why = this is

> more

> complicated than working out the ordering of nodes. And I do think = that the

> PCC

> should be spared the complexity of knowing or working out any = sequencing for

> the

> path.

[Dhruv Dhody>] Domain sequence would either be = pre configured or computed by some other means (eg. HPCE). Incase of = HPCE, Parent PCE can determine the correct order and specify the order = as its usually done in ERO; incase of admin has configured it at = PCC, IMHO admin is well aware of the sequence (it is a sequence = afterall).

I am aware of some = implementation of = CSPF that requires ordering esp in = case of strict hops. So I do believe in my opinion the complexity of PCE = to figure out domains = on its = own is high. =

Also consider P2MP where if the order is = not considered the complexity of the algorithm = at PCE will only increase.

 

> > In any case, the actual solution and encoding is open to = discussion. IF

> > the ordering inclusion is implicit, I have no objection for = using the

> > existing IRO and this includes your subsequent concerns with = its contents.

> >

> >> The algorithm in 3.4:

> >> - assumes only area IDs and AS numbers

> >> - assumes that a PCE knows at least one PCE responsible = for

> >>    each of its neighboring = domains

>  >

> > [Ramon] afaik, the algorithm was added recently in order to = simplify the

> > (apparently overkill and over-)specification of the IRO = sub-objects which

> > was also proposed by me in the aforementioned = mail

> > web/pce/current/msg02580.html (which tried, as a informational = exercise,

> > to also capture intra-domain objects). The motivation behind = both is to

> > clarify its usage. Depending on the outcomes of this and = further

> discussions

> > they can be elaborated, removed (by relying on the existing = documents) or

> > clarified.

> =

> OK

> =

> >> I would like the authors to take care that the identity of = a boundary node

> >> does not uniquely identify a next-hop domain (even if it = may be

> >> successfully used for domain routing given the knowledge = of the next

> >> domain, next boundary node, or egress node) and the text = should not

> >> imply that it does. This is hidden at the end of 3.4 some = time after the

> >> boundary node/link discussion.

> >

> > [Ramon] point taken. we will review the text = accordingly.

> >

> >> Shouldn't you allow "loose" hops in the domain = path? (i.e. gaps between

> >> domains).

> >

> > I don't see any special reason why we shouldn't, although one = concern I

> > have is how would this relate to RFC5440 statement "The L = bit of such

> > sub-object has no meaning within an = IRO"?

> =

> Ah, my bad. As above, the original (type 1) IRO has no ordering or = tightness

> of

> sequencing. Thus, it is just a list of things to = include.

> =

> *if* you stay with the type 2 IRO, and *if* you define ordering in = the type 2

> IRO (as currently written), then you need to consider the L = bit.

>

[Dhruv Dhody>] Yes = we will!

> >> Can I also mix other concepts with the domain path? What = about a

> consistent

> >> lambda, or a core node that needs to be on the = path?

> >

> > [Ramon] IMHO, there are two (decoupled) points = here:

> >

> > a) whether the current IRO has ordering constraints or = not

> >

> > b) If a new IRO is needed whether only domain-related info is = conveyed.

> >

> > An (authoritative ;-) ) answer for a) would be much = appreciated.

> =

> Ask JP ;-)

> =

> My reading agrees with yours (and my memory) as above. The IRO is = just a set

> of

> objects to be included. Presenting the elements of the set in any = order will

> have the same result (plus or minus ECMP situations and = peculiarities of

> specific PCE implementations).

> =

> > There was also the concern of separating the roles of = intra-domain path

> > computation IRO and the resolution of PCEs in a collaborative = setting.

>

> I'm not entirely sure I get this point. A PCE can only compute a = path segment

> that goes through its domain of responsibility - it will find all = elements in

> the IRO that it recognises as "local" and include them in = the segment it

> makes,

> and it will pass on all other elements to the other PCEs it = cooperates with.

> There is clearly a task for the "aggregating PCE" (which = may be the head of

> the

> chain, or may be the parent) to put the segments together according = to the

> complete IRO.

[Dhruv Dhody>] In = case of BRPC where the computation starts from the PCE(n); = domain-sequence serves the important purpose of reaching domain(n); if a = PCE has to go through IRO which has intra-domain segments (node, links) = plus the information on domain-sequence, it gets bit complicated to = handle. We specify clear separation for the very same = reason. We can provide suggested handling = when both IRO of type 1 and 2 exist. 

> =

> > For b), if we agree on the idea "the new object type = imposes

> > ordering constraints" I would not be against being like = any other

> > IRO. With a new IRO type we can be more concrete regarding = the

> > role of the must-process p-bit, what to do with unknown = objects

> > (locally to a PCE) i.e., nothing is said in IRO and XRO = objects what

> > the procedures are when a sub-object is "not found" = (in the TED?).

> =

> This seems to cut to a complexity question.

> We could allow a PCC to specify as much or as little of the = information about

> the path as it likes. This is certainly fully flexible, but it = seems to me to

> masively over-complicate the protocol and the functional model. = Isn't it the

> case that the PCE is capable of selecting the *best* path. Thus, = for example,

> there is no need for the PCC to say "I want a continuous = lambda for the

> segment

> over domain X" because that implies the PCC knows stuff about = domain X that

> the

> PCE is unaware of.

[Dhruv Dhody>] Domain-sequence is made of domains(AS = and area) and *optional* Boundary information (ABR, ASBR, inter-as = links). All this information is known to the admin as thus = configured at PCC or learned via parent PCE. = I don’t think there is any information = here that only PCC is aware of where as PCE is = not.

Also PCC can continue to specify as little = information and continue to use the existing = mechanims. 

> =

> > From the mail: "it is not clear to me what should be the = default

> > procedure for an unkonwn IRO subobject. It could be ignored = or

> > it could trigger an error. If we apply this to the domain = sequence,

> > I would say that an unknown subobject at this level should = trigger

> > some kind of high level error, like "PCE domain chain = broken" or

> > similar"

> =

> That is a good question, and there are two sub-species of = "unknown". The

> processing collapses to the same behavior, but it is worth looking = at them

> separately.

> =

> 1. I know the T value, but I can't find the identified = resource

> 2. I don't know the T value.

> =

> In the first case, the PCE processes the IRO to include as many of = the

> elements

> of the IRO as possible. If the PCE is passing the request onwards, = it is OK

> for

> it to fail to find the resource, and it can assume that the next = PCE might be

> able to satisfy the remaining elements of the IRO. On the other = hand, if the

> PCE

> is making an end-to-end (or edge-to-edge, or end-to-edge) path and = will

> return

> the response to a PCC (rather than pass it on) then the PCE must = fail if it

> cannot satisfy the IRO (this failure behavior is in RFC = 5440).

> =

> Now, I would hold that the second case can be handled identically = to the

> first

> case.

> =

> And ultimately, when the path segments are aggregated by a head-end = PCE or by

> a

> parent PCE, that PCE can check to see whether any elements of the = IRO are

> still

> missing.

> =

> There is, just one wrinkle in that case which is that the = aggregating PCE

> must

> understand all of the T values, or the IRO must be stripped and = returned on

> the

> response messages.

>

[Dhruv Dhody>] At a = time when we are considering enhance error and notification = handling [draft-pouyllau-pce-enhanced-errors], its important that our = inter-domain mechanism specify errors correctly and propagate them to = the PCC. In this document we made a humble attempt to specify the scope = of the IRO and clear error handling.

> >> In 3.5.7 I don't see that the domain sequence is = necessarily an

> alternative

> >> to the PCE sequence. There are cases where even with a = domain sequence,

> >> a PCE sequence is important.

> >

> > [Ramon] Personally, (although we still need to discuss it = more) I don't see

> > domain-sequence and pce-sequence as exclusive and I agree they = can

> > coexist. The whole 3.5.7 needs to be revisted, including J.P. = comments

> > during the meeting that some assertions were false (which is = true, brpc

> > may benefit from a domain sequence but does not require = it)

> =

> Agrred

> =

> >> Section 5 will need loads of work because the domain = sequence (even

> >> for inclusion, not reporting) provides information = valuable to an

> attacker.

> >

> >[Ramon] agreed.

> >

> > Thanks again,

> > Ramon

> =

> Very welcome.

> Most fun I have had all year :-)

> =

> Adrian

> =

> _______________________________________________

> Pce mailing list

> Pce@ietf.org

> https://www.ietf.org/mailman/listinfo/pce

------=_NextPart_000_0777_01CD1286.C5BF2B10-- From vishwas.ietf@gmail.com Wed Apr 4 07:44:43 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2A821F87EF for ; Wed, 4 Apr 2012 07:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkoqQ+s7mPke for ; Wed, 4 Apr 2012 07:44:42 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 604B321F87ED for ; Wed, 4 Apr 2012 07:44:42 -0700 (PDT) Received: by ghbg16 with SMTP id g16so207932ghb.31 for ; Wed, 04 Apr 2012 07:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JKxZtR1cP/0BwZOiNTztkc+aYSAfQ20kAvVlsSuCTes=; b=C71QLnO2yme95BjqrMlB66h/ICWmc9U4L+imJ6QpHI6CIGZNnoxBPL6wCkh3EIh/m0 v7x6nc47mGf2Lvz6iULix/Z1zphft83SkzNwewwsa75W+2eqkwj+OTsTtSpX9/gDOkgP oVfWKAGNZQV1w8oNIECy0xd3YwkNxu80/v9ODGVom7NhZ096wuw7AEZs0f/Rtso5TYB/ gd/Nb7IAEh2L31fUkg/R5SGUmI79FQNVgnYta0TB9fPkBaiN5EDyjlnQKALxIYt4kzrK Ho+4lY6V3kv2WEoby8rZu5pbwBgYT1RB4OL9yL8tbMh+xS+pYjkwl19/2bLQ6JVerOJr qqwQ== MIME-Version: 1.0 Received: by 10.60.21.103 with SMTP id u7mr24991809oee.11.1333550681578; Wed, 04 Apr 2012 07:44:41 -0700 (PDT) Received: by 10.182.36.41 with HTTP; Wed, 4 Apr 2012 07:44:41 -0700 (PDT) In-Reply-To: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> Date: Wed, 4 Apr 2012 07:44:41 -0700 Message-ID: From: Vishwas Manral To: JP Vasseur Content-Type: multipart/alternative; boundary=e89a8ff1c71eaa5a8204bcdb7664 Cc: pce@ietf.org Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:44:43 -0000 --e89a8ff1c71eaa5a8204bcdb7664 Content-Type: text/plain; charset=ISO-8859-1 Support adoption. -Vishwas On Thu, Mar 29, 2012 at 9:29 AM, JP Vasseur wrote: > Dear all, > > We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 > a PCE Working Group during our PCE WG meeting but > as usual we'd like to confirm on the mailing list. > > Could you please let us know if you are in favor/opposed to adopting > draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? > > Thanks. > > JP and Julien. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --e89a8ff1c71eaa5a8204bcdb7664 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support adoption.

-Vishwas

On Thu,= Mar 29, 2012 at 9:29 AM, JP Vasseur <jpv@cisco.com> wrote:
Dear all,

We had a p= retty strong support for adopting=A0draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but
as usual we'd like to confirm on the mailing list.

<= /div>
Could you please let us know if you are in favor/opposed to adopt= ing draft-dhody-pce-pcep-domain-sequence-02=A0as a PCE WG Document ?

Thanks.

JP and Julien.

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce


--e89a8ff1c71eaa5a8204bcdb7664-- From wenhu.lu@ericsson.com Wed Apr 4 09:45:04 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB2721F8733 for ; Wed, 4 Apr 2012 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7ZP8rG0tmNb for ; Wed, 4 Apr 2012 09:45:04 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DF40721F86B1 for ; Wed, 4 Apr 2012 09:45:03 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q34Gishb004304 for ; Wed, 4 Apr 2012 11:44:56 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 4 Apr 2012 12:44:49 -0400 From: Wenhu Lu To: "pce@ietf.org" Date: Wed, 4 Apr 2012 12:44:48 -0400 Thread-Topic: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Thread-Index: Ac0NyUrMfkydw1I4Tw+8YSKy+VJmawEuN1JQ Message-ID: <8249B703AE8442429AF89B86E8206AA26F4E0BE604@EUSAACMS0703.eamcs.ericsson.se> References: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> In-Reply-To: <5B30AA9C-FB42-4216-8B3B-854F13A0B93D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8249B703AE8442429AF89B86E8206AA26F4E0BE604EUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:45:04 -0000 --_000_8249B703AE8442429AF89B86E8206AA26F4E0BE604EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, support. Thanks, -wenhu ________________________________ From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Va= sseur Sent: Thursday, March 29, 2012 9:30 AM To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PC= E WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-seq= uence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-= dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. --_000_8249B703AE8442429AF89B86E8206AA26F4E0BE604EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes,=20 support.
 
Thanks,
-wenhu

From: pce-bounces@ietf.org=20 [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur
Sent:=20 Thursday, March 29, 2012 9:30 AM
To: pce@ietf.org
Subject:<= /B>=20 [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE=20 WG

Dear all,

We had a pretty strong support for adopting draft-dhody= -pce-pcep-domain-sequence-02=20 a PCE Working Group during our PCE WG meeting but
as usual we'd like to confirm on the mailing list.

Could you please let us know if you are in favor/opposed to adopting=20 draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ?

Thanks.

JP and Julien.
--_000_8249B703AE8442429AF89B86E8206AA26F4E0BE604EUSAACMS0703e_-- From julien.meuric@orange.com Thu Apr 5 02:58:20 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2C421F86A8 for ; Thu, 5 Apr 2012 02:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MA81XCZ9wue for ; Thu, 5 Apr 2012 02:58:20 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id DCE2421F86A6 for ; Thu, 5 Apr 2012 02:58:19 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 706A25D89A1; Thu, 5 Apr 2012 11:58:16 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 64E2B5D8979; Thu, 5 Apr 2012 11:58:16 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 11:58:16 +0200 Received: from [10.193.71.73] ([10.193.71.73]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 11:58:16 +0200 Message-ID: <4F7D6CB7.1030703@orange.com> Date: Thu, 05 Apr 2012 11:58:15 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: dhruv.dhody@huawei.com References: <0e5d01cd0df8$ebed2450$c3c76cf0$@olddog.co.uk> <0ABEE34E-BD75-44B9-BF04-B3A2D28635AE@cisco.com> <4F76CDFC.6010704@cttc.es> <06d201cd1183$f2ef00f0$d8cd02d0$@olddog.co.uk> <077601cd1258$ac06ef10$0414cd30$@dhody@huawei.com> In-Reply-To: <077601cd1258$ac06ef10$0414cd30$@dhody@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Apr 2012 09:58:16.0088 (UTC) FILETIME=[9EF61980:01CD1312] Cc: pce@ietf.org Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:58:20 -0000 Hi Dhruv. In any case, what you propose is the expected way of progressing a WG document. Thank you for mentioning it: it is always better when authors open the discussion themselves. Another item to be discussed is on the type of document (standard track / experimental): feedback on this from the WG (especially implementers, if any) would also be welcome. Thanks Julien Le 04/04/2012 13:47, Dhruv Dhody a écrit : > Once the WG has made thedecisionon theadoption, wecanre-poll theWG and > get consensus onthe issue of encoding domain-sequence.Authors do have > a preference butweare completely open for what the WG consensus > dictatesand revise the document accordingly. From Suresh.b.r@huawei.com Wed Apr 4 07:12:08 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12A321F8711 for ; Wed, 4 Apr 2012 07:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqZy9s6+xvN4 for ; Wed, 4 Apr 2012 07:12:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7BF21F8575 for ; Wed, 4 Apr 2012 07:12:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEY36170; Wed, 04 Apr 2012 10:12:00 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 06:20:33 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 06:20:37 -0700 Received: from blrprnc03ns (10.18.96.92) by szxeml420-hub.china.huawei.com (10.82.67.159) with Microsoft SMTP Server id 14.1.323.3; Wed, 4 Apr 2012 21:20:34 +0800 From: Suresh To: Date: Wed, 4 Apr 2012 18:50:24 +0530 Message-ID: <002f01cd1265$b76ad080$26407180$@b.r@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CD1293.D1230C80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0NyTFHZcwj34WfQtu7+UHpyMcwqQAX03MwAQ9IKyA= Content-Language: en-us X-Originating-IP: [10.18.96.92] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 05 Apr 2012 08:34:00 -0700 Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:12:08 -0000 ------=_NextPart_000_0030_01CD1293.D1230C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I Support. Regards Suresh From: Suresh [mailto:suresh.b.r@huawei.com] Sent: Friday, March 30, 2012 9:22 AM To: 'JP Vasseur' Subject: RE: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG I Support. Regards Suresh From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, March 29, 2012 10:00 PM To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. ------=_NextPart_000_0030_01CD1293.D1230C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I Support.

 

Regards

Suresh

 

 

From:= = Suresh [mailto:suresh.b.r@huawei.com]
Sent: Friday, March 30, = 2012 9:22 AM
To: 'JP Vasseur'
Subject: RE: [Pce] = Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE = WG

 

I Support.

 

Regards

Suresh

 

From:= = pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Thursday, March 29, 2012 10:00 = PM
To: pce@ietf.org
Subject: [Pce] Adopting = draft-dhody-pce-pcep-domain-sequence-02 as a new PCE = WG

 

Dear = all,

 

We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 = a PCE Working Group during our PCE WG meeting = but

as usual we'd like to = confirm on the mailing list.

 

Could you please let us know if you are in = favor/opposed to adopting = draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document = ?

 

Thanks.

 

JP and Julien.

------=_NextPart_000_0030_01CD1293.D1230C80-- From jpv@cisco.com Thu Apr 5 15:16:22 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045DB21F84A5 for ; Thu, 5 Apr 2012 15:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlDA9UugXyQR for ; Thu, 5 Apr 2012 15:16:21 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 64FDB21F86A4 for ; Thu, 5 Apr 2012 15:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=6940; q=dns/txt; s=iport; t=1333664181; x=1334873781; h=from:subject:date:references:to:message-id:mime-version; bh=fVgBnkYs+4JhBYJu45gNCcRN1r6rUeFTfg5Ed/4VF0k=; b=MNQezgTtr7tbxv8GyOUp8gvlOneCTUOBeIxx1D63wIT3kbVQYrahtElW S2NSWUf6UIyuMcDll/O/h7tu1mKAbufKi59ZJE52IDnPQxziSaxhQOOY/ iNqE/17n/4GryTMTIb/o5ewGFDnLUsADlJdLBFnIhh5nFya8EU54M9NZC I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAG8Yfk+rRDoI/2dsb2JhbABFuHOBB4IJAQEBAwEBAQEPAVsQCxwDAQIvJx8HAggZCQsOh2cEAQuaSJ9gj3djBIhZjRKLOoMRgWmDBw X-IronPort-AV: E=Sophos;i="4.75,378,1330905600"; d="scan'208,217";a="36699591" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 05 Apr 2012 22:16:18 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q35MGI1W022673 for ; Thu, 5 Apr 2012 22:16:18 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 15:16:18 -0700 Received: from dhcp-171-68-123-41.cisco.com ([171.68.123.41]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 15:16:18 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary="Apple-Mail=_F43B5B43-2498-4375-8B01-C1727697A867" Date: Thu, 5 Apr 2012 13:57:13 -0700 References: <20120405171116.19043.3710.idtracker@ietfa.amsl.com> To: pce@ietf.org Message-Id: <99037864-CD37-4A42-9878-EE96AF51D88E@cisco.com> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 05 Apr 2012 22:16:18.0462 (UTC) FILETIME=[B95023E0:01CD1379] Subject: [Pce] Fwd: I-D Action: draft-polk-ipr-disclosure-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 22:16:22 -0000 --Apple-Mail=_F43B5B43-2498-4375-8B01-C1727697A867 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii fyi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-polk-ipr-disclosure-02.txt > Date: April 5, 2012 10:11:16 AM PDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Promoting Compliance with Intellectual = Property Rights (IPR) Disclosure Rules > Author(s) : Tim Polk > Peter Saint-Andre > Filename : draft-polk-ipr-disclosure-02.txt > Pages : 13 > Date : 2012-04-05 >=20 > The disclosure process for intellectual property rights (IPR) in = IETF > stream documents is essential to the accurate development of > community consensus. However, this process is not always followed = by > participants during IETF standardization. Regardless of the cause = or > motivation, noncompliance with IPR disclosure rules can derail or > delay completion of standards documents. This document describes > strategies for promoting compliance with the IPR disclosure rules. > The strategies are primarily intended for area directors, working > group chairs, and working group secretaries. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-polk-ipr-disclosure-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-polk-ipr-disclosure-02.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_F43B5B43-2498-4375-8B01-C1727697A867 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: I-D Action: = draft-polk-ipr-disclosure-02.txt
Date: April 5, 2012 = 10:11:16 AM PDT
Reply-To: = internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.

Title =           : Promoting = Compliance with Intellectual Property Rights (IPR) Disclosure = Rules
= Author(s)       : Tim Polk
=             &n= bsp;           &nbs= p;Peter Saint-Andre
Filename =        : = draft-polk-ipr-disclosure-02.txt
Pages =           : = 13
= Date =            : = 2012-04-05

  The disclosure process for intellectual = property rights (IPR) in IETF
  stream documents is = essential to the accurate development of
  community = consensus.  However, this process is not always followed by
=   participants during IETF standardization.  Regardless = of the cause or
  motivation, noncompliance with IPR = disclosure rules can derail or
  delay completion of = standards documents.  This document describes
=   strategies for promoting compliance with the IPR disclosure = rules.
  The strategies are primarily intended for area = directors, working
  group chairs, and working group = secretaries.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-polk-ipr-disclosure-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

This Internet-Draft can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-polk-ipr-disclosure-02.txt=

_______________________________________________
I-D-Announce = mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= = --Apple-Mail=_F43B5B43-2498-4375-8B01-C1727697A867-- From julien.meuric@orange.com Wed Apr 11 07:03:02 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057CC11E814C for ; Wed, 11 Apr 2012 07:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9P+SXodS4yq for ; Wed, 11 Apr 2012 07:03:01 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id D0B7C11E8120 for ; Wed, 11 Apr 2012 07:03:00 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 84CCE5D8979 for ; Wed, 11 Apr 2012 16:02:58 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 7D77E5D891C for ; Wed, 11 Apr 2012 16:02:58 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 16:02:58 +0200 Received: from [10.193.71.73] ([10.193.71.73]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 16:02:58 +0200 Message-ID: <4F858F11.2040802@orange.com> Date: Wed, 11 Apr 2012 16:02:57 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2012 14:02:58.0073 (UTC) FILETIME=[CC95B890:01CD17EB] Subject: [Pce] IETF 83 Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:03:02 -0000 Hi all. A first version of the minutes for our meeting in Paris is available: http://www.ietf.org/proceedings/83/minutes/minutes-83-pce.html (thank you Dan for taking and polishing them). Should you have any comment, please contact the chairs, CCing our secretary. Regards, Julien From julien.meuric@orange.com Wed Apr 11 07:39:22 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBA411E80A5 for ; Wed, 11 Apr 2012 07:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXFZOAb1IEmB for ; Wed, 11 Apr 2012 07:39:22 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1D911E8080 for ; Wed, 11 Apr 2012 07:39:22 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E00DB411092; Wed, 11 Apr 2012 16:39:20 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id D8E51410E45; Wed, 11 Apr 2012 16:39:20 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 16:39:20 +0200 Received: from [10.193.71.73] ([10.193.71.73]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 16:39:20 +0200 Message-ID: <4F859798.7070408@orange.com> Date: Wed, 11 Apr 2012 16:39:20 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: Meral Shirazipour References: <25DC600D0CC1F2479C7053ADEB93004E67C2A03277@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <25DC600D0CC1F2479C7053ADEB93004E67C2A03277@EUSAACMS0703.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Apr 2012 14:39:20.0523 (UTC) FILETIME=[E16D29B0:01CD17F0] Cc: "pce@ietf.org" , JP Vasseur Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:39:22 -0000 Hi Meral. I believe the freshly posted minutes bring an answer to you question. Beyond the generic scope in which this I-D was presented, I feel the advantages and drawbacks of that proposal are off balance. On the one hand, focusing on a single PCE solution removes a lot from the PCE architecture (or requires heavy complementary mechanisms, i.e. yet another strong shortcoming). On the other hand, it aims at "saving a few crankbacks" (quoting Oscar) in the control plane, which is likely to end up by saving a negligible time with respect to the data plane timescale, especially for WDM where the label resource is scarcer (1st and longer use case in the draft). Finally, knowing that an implementation could make use of the proposed idea based on a simple PCE policy, such an unbalanced protocol extension seems more than questionable... Regards, Julien Le 29/03/2012 19:55, Meral Shirazipour a écrit : > > Hi JP, > > I may have missed part of the discussion today after Oscar > presented. What was the next step for draft: > http://tools.ietf.org/html/draft-gonzalezdedios-pce-reservation-state-01 ? > > Thanks, > > Meral > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From meral.shirazipour@ericsson.com Wed Apr 11 10:53:38 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA4711E808D for ; Wed, 11 Apr 2012 10:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1p-DqB0Kobr for ; Wed, 11 Apr 2012 10:53:35 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A720611E8089 for ; Wed, 11 Apr 2012 10:53:34 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3BHrUsT031966; Wed, 11 Apr 2012 12:53:34 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 11 Apr 2012 13:53:32 -0400 From: Meral Shirazipour To: Julien Meuric Date: Wed, 11 Apr 2012 13:53:28 -0400 Thread-Topic: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ? Thread-Index: Ac0X8Ocy+TA9HZEWRRSPBDmX/iRUhQAGE0hA Message-ID: <25DC600D0CC1F2479C7053ADEB93004E67C2C3DE79@EUSAACMS0703.eamcs.ericsson.se> References: <25DC600D0CC1F2479C7053ADEB93004E67C2A03277@EUSAACMS0703.eamcs.ericsson.se> <4F859798.7070408@orange.com> In-Reply-To: <4F859798.7070408@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pce@ietf.org" , JP Vasseur Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:53:38 -0000 Hi, Thank you for the reply.=20 IMPO there is a need for such a functionality: if after all the PCEs proces= sing work we have to rely on crankback, then the question is why do we use= PCEs at the first place. There may also be other use cases that can benefi= t from prereservation, and we should not only consider this from a "cranck= back saving" angle. It seems that there are 2 distinct points to the discussion regarding the d= raft: 1- Consensus that there is a problem if resources are not pre-reserved.=20 2- There are various ways to solve this problem, each with pros and cons. I think point #1 is clear enough to anyone who faced or studied the problem= . And if I recall correctly, the comments after Oscar's presentation (inclu= ding those regarding the NMS-PCE relation) were all related to point #2 abo= ve. I think these comments can all be addressed by the wg.=20 Best regards, Meral -----Original Message----- From: Julien Meuric [mailto:julien.meuric@orange.com]=20 Sent: April-11-12 10:39 AM To: Meral Shirazipour Cc: JP Vasseur; pce@ietf.org Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step = ? Hi Meral. I believe the freshly posted minutes bring an answer to you question. Beyond the generic scope in which this I-D was presented, I feel the advant= ages and drawbacks of that proposal are off balance. On the one hand, focus= ing on a single PCE solution removes a lot from the PCE architecture (or re= quires heavy complementary mechanisms, i.e. yet another strong shortcoming)= . On the other hand, it aims at "saving a few crankbacks" (quoting Oscar) i= n the control plane, which is likely to end up by saving a negligible time = with respect to the data plane timescale, especially for WDM where the labe= l resource is scarcer (1st and longer use case in the draft). Finally, knowing that an implementation could make use of the proposed idea= based on a simple PCE policy, such an unbalanced protocol extension seems = more than questionable... Regards, Julien Le 29/03/2012 19:55, Meral Shirazipour a =E9crit : > > Hi JP, > > I may have missed part of the discussion today after Oscar=20 > presented. What was the next step for draft: > http://tools.ietf.org/html/draft-gonzalezdedios-pce-reservation-state-01 = ? > > Thanks, > > Meral > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From leeyoung@huawei.com Wed Apr 11 12:01:03 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD5821F8595 for ; Wed, 11 Apr 2012 12:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND9y4J8ToN3x for ; Wed, 11 Apr 2012 12:01:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 345B921F84FC for ; Wed, 11 Apr 2012 12:00:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEV36810; Wed, 11 Apr 2012 15:00:55 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Apr 2012 11:59:38 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 11 Apr 2012 11:59:39 -0700 From: Leeyoung To: Meral Shirazipour , Julien Meuric Thread-Topic: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ? Thread-Index: Ac0N1QUWCVnP+JNvQ7K2bM1mBY9b4AKVohkAAAbHsAAADKmX8A== Date: Wed, 11 Apr 2012 18:59:39 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1720C9133B@dfweml511-mbx.china.huawei.com> References: <25DC600D0CC1F2479C7053ADEB93004E67C2A03277@EUSAACMS0703.eamcs.ericsson.se> <4F859798.7070408@orange.com> <25DC600D0CC1F2479C7053ADEB93004E67C2C3DE79@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <25DC600D0CC1F2479C7053ADEB93004E67C2C3DE79@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.193] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" , JP Vasseur Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:01:03 -0000 Hi Meral, I agree with your analysis on Point #1. Many PCE implementations as far as = I know use this kind of mechanism in place. Regarding comment on the use of= crankback, this may not be the best mechanism to depend on especially when= dealing with restoration situations which is one of the main applications = for Oscar's draft.=20 On Point #2, if PCE is the best mechanism to do this function is debatable;= yet I think it is a good way to support this function. Again for restorati= on situations NMS based solution may not be the best choice due to timeline= ss factor.=20 Regards, Young=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Meral= Shirazipour Sent: Wednesday, April 11, 2012 12:53 PM To: Julien Meuric Cc: pce@ietf.org; JP Vasseur Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step = ? Hi, Thank you for the reply.=20 IMPO there is a need for such a functionality: if after all the PCEs proces= sing work we have to rely on crankback, then the question is why do we use= PCEs at the first place. There may also be other use cases that can benefi= t from prereservation, and we should not only consider this from a "cranck= back saving" angle. It seems that there are 2 distinct points to the discussion regarding the d= raft: 1- Consensus that there is a problem if resources are not pre-reserved.=20 2- There are various ways to solve this problem, each with pros and cons. I think point #1 is clear enough to anyone who faced or studied the problem= . And if I recall correctly, the comments after Oscar's presentation (inclu= ding those regarding the NMS-PCE relation) were all related to point #2 abo= ve. I think these comments can all be addressed by the wg.=20 Best regards, Meral -----Original Message----- From: Julien Meuric [mailto:julien.meuric@orange.com]=20 Sent: April-11-12 10:39 AM To: Meral Shirazipour Cc: JP Vasseur; pce@ietf.org Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step = ? Hi Meral. I believe the freshly posted minutes bring an answer to you question. Beyond the generic scope in which this I-D was presented, I feel the advant= ages and drawbacks of that proposal are off balance. On the one hand, focus= ing on a single PCE solution removes a lot from the PCE architecture (or re= quires heavy complementary mechanisms, i.e. yet another strong shortcoming)= . On the other hand, it aims at "saving a few crankbacks" (quoting Oscar) i= n the control plane, which is likely to end up by saving a negligible time = with respect to the data plane timescale, especially for WDM where the labe= l resource is scarcer (1st and longer use case in the draft). Finally, knowing that an implementation could make use of the proposed idea= based on a simple PCE policy, such an unbalanced protocol extension seems = more than questionable... Regards, Julien Le 29/03/2012 19:55, Meral Shirazipour a =E9crit : > > Hi JP, > > I may have missed part of the discussion today after Oscar=20 > presented. What was the next step for draft: > http://tools.ietf.org/html/draft-gonzalezdedios-pce-reservation-state-01 = ? > > Thanks, > > Meral > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From adrian@olddog.co.uk Thu Apr 12 06:22:07 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAC021F8548 for ; Thu, 12 Apr 2012 06:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OR3SdLrJF3HE for ; Thu, 12 Apr 2012 06:22:06 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id AD27321F84FD for ; Thu, 12 Apr 2012 06:22:04 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3CDLtoR000610; Thu, 12 Apr 2012 14:21:55 +0100 Received: from 950129200 (AGrenoble-551-1-40-179.w92-157.abo.wanadoo.fr [92.157.199.179]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3CDLo77000590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Apr 2012 14:21:52 +0100 From: "Adrian Farrel" To: "'Leeyoung'" , "'Meral Shirazipour'" , "'Julien Meuric'" References: <25DC600D0CC1F2479C7053ADEB93004E67C2A03277@EUSAACMS0703.eamcs.ericsson.se> <4F859798.7070408@orange.com> <25DC600D0CC1F2479C7053ADEB93004E67C2C3DE79@EUSAACMS0703.eamcs.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1720C9133B@dfweml511-mbx.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1720C9133B@dfweml511-mbx.china.huawei.com> Date: Thu, 12 Apr 2012 14:21:52 +0100 Message-ID: <16a901cd18af$3b785e20$b2691a60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJhcmToTh9sWIPhun4fRbldkC8b+wKGUOCjAnVEITwBNC0WzpU8809A Content-Language: en-gb Cc: pce@ietf.org, 'JP Vasseur' Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next step ? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 13:22:07 -0000 Hi, My two cents here as an individual are: optimise for the general case = and be very careful about optimising for the specific. The thing to avoid is = complexity that creeps into the general implementation in order to enhance behavior = in a corner case. I am not commenting on whether this *is* a corner case. To do that I = would have to read the draft more carefully, but it seems to me that it is a = question of likely allocation congestion versus required setup speed. Having built = and deployed this stuff in optical equipment, I think that the existing = signaling mechanisms are usually enough. However, I will note that many PCEs perform "sticky" reservations as a = matter of course (indeed many LSRs with head-end PCE functionality have done this = since the start of MPLS-TE). This has been a local policy and one that has not = needed protocol support. Indeed, how is a PCC to know whether reservations = should be sticky or not except by local policy configuration? And if so, isn't it = easier to configure the one or two PCEs rather than the very many PCCs? Lastly, when looking at sticky reservations, and assuming there is an = intent to arrive at a "perfect" non-crankback situation, we would have to address synchronisation across multiple PCEs. Cheers, Adrian > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Leeyoung > Sent: 11 April 2012 20:00 > To: Meral Shirazipour; Julien Meuric > Cc: pce@ietf.org; JP Vasseur > Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next = step ? >=20 > Hi Meral, >=20 > I agree with your analysis on Point #1. Many PCE implementations as = far as I know > use this kind of mechanism in place. Regarding comment on the use of crankback, > this may not be the best mechanism to depend on especially when = dealing with > restoration situations which is one of the main applications for = Oscar's draft. >=20 > On Point #2, if PCE is the best mechanism to do this function is = debatable; yet I > think it is a good way to support this function. Again for restoration situations > NMS based solution may not be the best choice due to timeliness = factor. >=20 > Regards, > Young >=20 > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = Meral > Shirazipour > Sent: Wednesday, April 11, 2012 12:53 PM > To: Julien Meuric > Cc: pce@ietf.org; JP Vasseur > Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next = step ? >=20 > Hi, > Thank you for the reply. > IMPO there is a need for such a functionality: if after all the PCEs processing work > we have to rely on crankback, then the question is why do we use PCEs = at the > first place. There may also be other use cases that can benefit from > prereservation, and we should not only consider this from a = "cranckback saving" > angle. >=20 > It seems that there are 2 distinct points to the discussion regarding = the draft: > 1- Consensus that there is a problem if resources are not = pre-reserved. > 2- There are various ways to solve this problem, each with pros and = cons. >=20 > I think point #1 is clear enough to anyone who faced or studied the = problem. And > if I recall correctly, the comments after Oscar's presentation = (including those > regarding the NMS-PCE relation) were all related to point #2 above. I = think these > comments can all be addressed by the wg. >=20 > Best regards, > Meral >=20 >=20 >=20 >=20 > -----Original Message----- > From: Julien Meuric [mailto:julien.meuric@orange.com] > Sent: April-11-12 10:39 AM > To: Meral Shirazipour > Cc: JP Vasseur; pce@ietf.org > Subject: Re: [Pce] draft-gonzalezdedios-pce-reservation-state-01 next = step ? >=20 > Hi Meral. >=20 > I believe the freshly posted minutes bring an answer to you question. >=20 > Beyond the generic scope in which this I-D was presented, I feel the advantages > and drawbacks of that proposal are off balance. On the one hand, = focusing on a > single PCE solution removes a lot from the PCE architecture (or = requires heavy > complementary mechanisms, i.e. yet another strong shortcoming). On the = other > hand, it aims at "saving a few crankbacks" (quoting Oscar) in the = control plane, > which is likely to end up by saving a negligible time with respect to = the data plane > timescale, especially for WDM where the label resource is scarcer (1st = and longer > use case in the draft). > Finally, knowing that an implementation could make use of the proposed = idea > based on a simple PCE policy, such an unbalanced protocol extension = seems > more than questionable... >=20 > Regards, >=20 > Julien >=20 >=20 > Le 29/03/2012 19:55, Meral Shirazipour a =E9crit : > > > > Hi JP, > > > > I may have missed part of the discussion today after Oscar > > presented. What was the next step for draft: > > = http://tools.ietf.org/html/draft-gonzalezdedios-pce-reservation-state-01 = ? > > > > Thanks, > > > > Meral > > > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From internet-drafts@ietf.org Mon Apr 23 14:59:18 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F054F21E802B; Mon, 23 Apr 2012 14:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC5hrXElrt4E; Mon, 23 Apr 2012 14:59:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C30D21E800F; Mon, 23 Apr 2012 14:59:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01 Message-ID: <20120423215917.17757.42496.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 14:59:17 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:59:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Grou= p of the IETF. Title : PCEP Requirements for WSON Routing and Wavelength Assign= ment Author(s) : Young Lee Greg Bernstein Jonas Martensson Tomonori Takeda Takehiro Tsuritani Oscar Gonzalez de Dios Filename : draft-ietf-pce-wson-routing-wavelength-07.txt Pages : 13 Date : 2012-04-23 This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-= 07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-0= 7.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ From leeyoung@huawei.com Wed Apr 25 12:48:59 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD82B21F890A for ; Wed, 25 Apr 2012 12:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4ves1kNbFEG for ; Wed, 25 Apr 2012 12:48:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 197C521F8826 for ; Wed, 25 Apr 2012 12:48:59 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN40367; Wed, 25 Apr 2012 15:48:58 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Apr 2012 12:47:14 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 25 Apr 2012 12:47:09 -0700 From: Leeyoung To: "pce@ietf.org" Thread-Topic: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-07.txt Thread-Index: AQHNIZxcz5oR8bdaLUmEIw/vWjgUiJar9HIg Date: Wed, 25 Apr 2012 19:47:08 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1720C929EA@dfweml511-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Pce] FW: I-D Action: draft-ietf-pce-wson-routing-wavelength-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:48:59 -0000 Hi, The changes are mostly editorial nature. This document has been quite stabl= e and is ready to move to WG LC. The solution draft will be shortly updated= .=20 If you have any question/comment, please send them to the list. Thanks. Young -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of inter= net-drafts@ietf.org Sent: Monday, April 23, 2012 4:59 PM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Grou= p of the IETF. Title : PCEP Requirements for WSON Routing and Wavelength Assign= ment Author(s) : Young Lee Greg Bernstein Jonas Martensson Tomonori Takeda Takehiro Tsuritani Oscar Gonzalez de Dios Filename : draft-ietf-pce-wson-routing-wavelength-07.txt Pages : 13 Date : 2012-04-23 This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-= 07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pce-wson-routing-wavelength-0= 7.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From leeyoung@huawei.com Mon Apr 30 09:02:37 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573B321F8594 for ; Mon, 30 Apr 2012 09:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mvjv96yW-Srz for ; Mon, 30 Apr 2012 09:02:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D721F8617 for ; Mon, 30 Apr 2012 09:02:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFS24393; Mon, 30 Apr 2012 12:02:36 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 09:01:24 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.78]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 30 Apr 2012 09:01:20 -0700 From: Leeyoung To: "pce@ietf.org" Thread-Topic: New Version Notification for draft-lee-pce-wson-rwa-ext-04.txt Thread-Index: AQHNJukpWeY2031c9Uueh8gh/mwg8ZazhMQQ Date: Mon, 30 Apr 2012 16:01:20 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1720C9C7D8@dfweml511-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.237] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: JP Vasseur Subject: [Pce] FW: New Version Notification for draft-lee-pce-wson-rwa-ext-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:02:37 -0000 SGksDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtbGVlLXBjZS13c29uLXJ3YS1leHQt MDQudHh0DQoNClBDRVAgZXh0ZW5zaW9ucyBmb3IgV1NPTiBSV0EgZHJhZnQgaGFzIGJlZW4gdXBk YXRlZC4gVGhlIGRyYWZ0IHJlbW92ZWQgYWxsIHRoZSBub24tc2NvcGUgaXNzdWVzIGFuZCB1bmRl cndlbnQgc29tZSBlZGl0b3JpYWwgY2xlYW4tdXBzLg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1l bnRzL2lzc3VlcyB0byB0aGUgbGlzdHMuIA0KDQpCZXN0IHJlZ2FyZHMsDQoNClJhbW9uIGFuZCBZ b3VuZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRh eSwgQXByaWwgMzAsIDIwMTIgMTA6NTIgQU0NClRvOiBMZWV5b3VuZw0KQ2M6IHJhbW9uLmNhc2Vs bGFzQGN0dGMuZXMNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt bGVlLXBjZS13c29uLXJ3YS1leHQtMDQudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1sZWUtcGNlLXdzb24tcndhLWV4dC0wNC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBZb3VuZyBMZWUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpG aWxlbmFtZToJIGRyYWZ0LWxlZS1wY2Utd3Nvbi1yd2EtZXh0DQpSZXZpc2lvbjoJIDA0DQpUaXRs ZToJCSBQQ0VQIEV4dGVuc2lvbiBmb3IgV1NPTiBSb3V0aW5nIGFuZCBXYXZlbGVuZ3RoIEFzc2ln bm1lbnQNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA0LTMwDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMjINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRyYWZ0 IHByb3ZpZGVzIHRoZSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgY29tbXVuaWNhdGlvbg0KICAg UHJvdG9jb2wgKFBDRVApIGV4dGVuc2lvbnMgZm9yIHRoZSBzdXBwb3J0IG9mIFJvdXRpbmcgYW5k IFdhdmVsZW5ndGgNCiAgIEFzc2lnbm1lbnQgKFJXQSkgaW4gV2F2ZWxlbmd0aCBTd2l0Y2hlZCBP cHRpY2FsIE5ldHdvcmtzIChXU09OKS4NCiAgIExpZ2h0cGF0aCBwcm92aXNpb25pbmcgaW4gV1NP TnMgcmVxdWlyZXMgYSByb3V0aW5nIGFuZCB3YXZlbGVuZ3RoDQogICBhc3NpZ25tZW50IChSV0Ep IHByb2Nlc3MuICBGcm9tIGEgcGF0aCBjb21wdXRhdGlvbiBwZXJzcGVjdGl2ZSwNCiAgIHdhdmVs ZW5ndGggYXNzaWdubWVudCBpcyB0aGUgcHJvY2VzcyBvZiBkZXRlcm1pbmluZyB3aGljaCB3YXZl bGVuZ3RoDQogICBjYW4gYmUgdXNlZCBvbiBlYWNoIGhvcCBvZiBhIHBhdGggYW5kIGZvcm1zIGFu IGFkZGl0aW9uYWwgcm91dGluZw0KICAgY29uc3RyYWludCB0byBvcHRpY2FsIGxpZ2h0IHBhdGgg Y29tcHV0YXRpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0K