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 B5A99C14F5F3 for ; Tue, 30 Jul 2024 02:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20230601.gappssmtp.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqPh9XQEgMZX for ; Tue, 30 Jul 2024 02:46:26 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B174EC14F685 for ; Tue, 30 Jul 2024 02:46:26 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id 46e09a7af769-709345dd01dso1538964a34.0 for ; Tue, 30 Jul 2024 02:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20230601.gappssmtp.com; s=20230601; t=1722332786; x=1722937586; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3cQQhD2A2c1zZxOhp66/c+M5alFMQj68VCqhSyb2BDc=; b=my0RC3S7GDyDKdaEtyU+civmQOUZmhpdSW5DQkqjz0L5Oc8GKzS/94jhCUTCDVtM5l vFuGL1Qr0zpeBK9Es4ciCVbscONXWY+mBPBPQTg2ZblJJ4Q2/+7vI9avW8tjDBI0kTTa Y8fuJrobMXddLPWFlqH/3NtpK/pPQbArzs7K2jp5bYlRrC9Um5mXYLZAmagM8HInOM2O /VFuYWRNj5dAWBMcuW+kgjLlZGWqF2reE7PJw+d+KhP/rh6nhDOiNa7nBWdOYANTFaAb mDPqVhNGKRISoXjsiq3FbzQfOwRg+cCWSGjq8PJe/Xllt6+9SJh4XKh3zEeVy/DoNWKD PteA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722332786; x=1722937586; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3cQQhD2A2c1zZxOhp66/c+M5alFMQj68VCqhSyb2BDc=; b=assBARvPCj6RNBdmy9tU//ZbiLM2Wx8lLlbQyj3RpvyJ0q4UTLdhD8LATMMLQszOaD SWBN8UirXDmecu+W6OAJgepI2ItQv/Vj7bycf2A3khpkVik4QHuc+q+l9h9VOXnk0WEy 4irIMyOovAy3tVoyRxmghRsuz2QKZ5pe6NAJXTedkm3wEeif66j4FRehOD7/qQyI2Ous AzymmSBb9hwPIeGjHjNAt5qKgH7czfopc6B6XxZg72EZA+ar6jx1MNVM3ZtcbcfhzSKl zTqH9c3csQyjWqlXlWNQOxlHYG/8VuH6qWa2F6NZQkhpZjSEeb6qlOdGJn4/7X0Kp+1A S9Rg== X-Forwarded-Encrypted: i=1; AJvYcCWzaTGX9sQyJKwg6iZU0jSeB1Kz5fNKmYMPHjVyeQbEyTkvRs7f5OEn7jLdhWfaOsfKO9ojYHwB/WvzPWA= X-Gm-Message-State: AOJu0Yynl/1PcohfPjhTrFKtJq9ThyKfFyB64aM46uQlPkePIEWSTlGV fm1ZMyznKa5jp+942TTibEujUc1puOgfhfI2n9qqNGytztzQGRR/syH3EKs0TRpn2ZGTtBQCLfW DSTqCXAXyVLcCnQGnnoTTp6t/R9HmUNC7pyxaRw== X-Google-Smtp-Source: AGHT+IER5NwKl/mfxVQXqMcuFPITVR4nTQmwZUiToqYnrPARNGwN521hCB98/PTXFJh5TkhkvVYm/TDJd3StZutqdxs= X-Received: by 2002:a05:6830:1212:b0:703:6c9d:cb81 with SMTP id 46e09a7af769-7095b7ad86dmr576609a34.3.1722332785589; Tue, 30 Jul 2024 02:46:25 -0700 (PDT) MIME-Version: 1.0 References: <09acf5face1d472a9267a5d92568dd64@huawei.com> In-Reply-To: From: Dhruv Dhody Date: Tue, 30 Jul 2024 02:45:47 -0700 Message-ID: To: "Andrew Stone (Nokia)" Content-Type: multipart/alternative; boundary="000000000000dedb29061e73d988" Message-ID-Hash: OVL7TGAFOZUBFBJMR2QQXVAZ223XLLDF X-Message-ID-Hash: OVL7TGAFOZUBFBJMR2QQXVAZ223XLLDF X-MailFrom: dd@dhruvdhody.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Cheng Li , "pce@ietf.org" , pce-chairs X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BPce=5D_Re=3A_Where_the_Controlled_ID_info_shuold_be_carried/enc?= =?utf-8?q?oded=3F?= List-Id: Path Computation Element Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000dedb29061e73d988 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, During the IETF 120 discussion, the conclusion was to choose option 1, which involves continuing to use the Open message to encode the ID space controlled by the PCE. It was suggested that a generic Notification mechanism could be developed to update the parameters exchanged during the Open message, outside of this I-D. Please respond here if you disagree with your reasoning. Thanks! Dhruv On Tue, Jul 9, 2024 at 12:51=E2=80=AFPM Andrew Stone (Nokia) wrote: > Hi all, > > > > I like the PcOpen + PcNotify idea, mainly because I hope we can > generically define a pattern of PcOpen content refresh without the need f= or > a session flap. Using PcOpen+PcNotify also becomes a bit more consistent > in approach with the similar state synchronization proposal for add/delet= e > PcOpen between PCE=E2=80=99s. I do not think we should add (even partial) > dependency on PCEP-LS to solve that generalized problem. I also do not > think we should overload PcRpt since the use of PcRpt is well understood = to > be about LSP state, and mucking with it to fit other content feels like > it's being overloaded. > > > > Therefore I think it comes down to a new message (PcOpenRefresh?) or > leveraging PcNotify. I currently don't see a block on using PcNotify for > this. > > > > To keep it simple I think the TLVs in the PcNotify should be a snapshot > equal to the same content as if this was PcOpen upon connect (i.e don't > send diff). In other words as an example with > draft-ietf-pce-controlled-id-space, if someone adds a new range to the PC= C, > the PcNotify would carry a LABEL-CONTROLS-SPACE-TLV which contains both > existing and new ranges and not build in add/remove/diff semantics inside > of the TLV itself. > > > > Thanks > > Andrew > > > > *From: *Cheng Li > *Date: *Tuesday, July 9, 2024 at 6:28 AM > *To: *Dhruv Dhody > *Cc: *pce@ietf.org , pce-chairs , > Samuel Sidor (ssidor) > *Subject: *RE: [Pce] Where the Controlled ID info shuold be > carried/encoded? > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > > Yes, I also think this combination is better. > > Option 1 Open msg can be used for initial report, and the rest update can > be reported by the Notification msg. > > > > Already recorded this in the slide. > > > > Cheng > > > > > > *From:* Dhruv Dhody > *Sent:* Tuesday, July 9, 2024 11:34 AM > *To:* Cheng Li > *Cc:* pce@ietf.org; pce-chairs ; Samuel Sidor > (ssidor) > *Subject:* Re: [Pce] Where the Controlled ID info shuold be > carried/encoded? > > > > Hi, > > > > Samuel made a suggestion to combine the options of using Open and > Notification together, I have now captured that in the notes page - > https://notes.ietf.org/draft-ietf-pce-controlled-id-space?view > > > > Feel free to add to the discussion here or on the notes page. > > > > Thanks! > > Dhruv > > > > On Sat, Jul 6, 2024 at 2:53=E2=80=AFPM Dhruv Dhody wr= ote: > > Hi Cheng, > > > > To facilitate this discussion I have created a notes page - > https://notes.ietf.org/draft-ietf-pce-controlled-id-space?view that > documents the various options. > > > > WG, > > > > Feel free to add things there but add your name for easy tracking. > > You can also add your preference for a solution and with reasoning at the > bottom or simply reply on this thread and I can keep the notes page > updated. > > > > Hope the WG finds this useful and it helps in converging on a way > forward... > > > > Thanks! > > Dhruv > > > > On Thu, Jun 20, 2024 at 10:46=E2=80=AFAM Cheng Li > wrote: > > Hi Guys=EF=BC=8C > > > > Thank you so much for your helpful review and comments of our draft > draft-ietf-pce-controlled-id-space. > > In the WG adoption, I can summarize our discussion into the below bullets= , > hope they are correct, > > 1. The draft is useful, and the mechanism defined in the draft is > needed, we should work on it. (Thanks!) > 2. We need to discuss the where the info should be carried in the > PCEP. Open Object seems not so good =E2=98=B9 > 3. TLV encoding should be updated to be more generic or let's avoid > the generic description and define specific sub-TLVs as needed. > > > > I see the reasons why we decided to carry the info in PCEP Open Object, > because it is a device-wide configuration info, which should not be > modified in the running state. We may face a lot of trouble of removing s= ome > IDs and then modify the range in a running network. However, we may also > need to handle the negotiation between PCC and PCE? Therefore, I am also > concerning about this. > > > > I like to hear your voice on this, which object/msg is appropriate to > carry the info? I am open with other options. > > > > Possible options could be > > l Open message > > l Use PCEP-LS encoding and make this a node attribute > > l New type of notification > > l New message/object > > > > Once we get the conclusion of this, we can go to the bullet 3, which is > much easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by > one, this can decouple the relations between IDs, though we may need to > delete the 'generic' words. > > > > Thoughts? > > Cheng > > > > _______________________________________________ > Pce mailing list -- pce@ietf.org > To unsubscribe send an email to pce-leave@ietf.org > > --000000000000dedb29061e73d988 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,=C2=A0

<= div class=3D"gmail_default" style=3D"font-family:trebuchet ms,sans-serif;co= lor:#073763">During the IETF 120 discussion, the conclusion was to choose o= ption 1, which involves continuing to use the Open message to encode the ID= space controlled by the PCE. It was suggested that a generic Notification = mechanism could be developed to update the parameters exchanged during the = Open message, outside of this I-D.=C2=A0

Please respond here if you disagree with your reasoning.=C2=A0
=

Thanks!=C2=A0
Dhruv


On Tue, Jul 9, 2024 at 12:51=E2=80= =AFPM Andrew Stone (Nokia) <an= drew.stone@nokia.com> wrote:

Hi all,

=C2=A0

I like the PcOpen + PcNotify idea, mainly because I hope we can g= enerically define a pattern of PcOpen content refresh without the need for = a session flap.=C2=A0 Using PcOpen+PcNotify also becomes a bit more consistent in approach with the similar state sync= hronization proposal for add/delete PcOpen between PCE=E2=80=99s. I do not = think we should add (even partial) dependency on PCEP-LS to solve that gene= ralized problem. I also do not think we should overload PcRpt since the use of PcRpt is well understood to be abou= t LSP state, and mucking with it to fit other content feels like it's b= eing overloaded.

=C2=A0

Therefore I think it comes down to a new message (PcOpenRefresh?)= or leveraging PcNotify. I currently don't see a block on using PcNotif= y for this.

=C2=A0

To keep it simple I think the TLVs in the PcNotify should be a sn= apshot equal to the same content as if this was PcOpen upon connect (i.e do= n't send diff).=C2=A0 In other words as an example with draft-ietf-pce-controlled-id-space, if someone adds a n= ew range to the PCC, the PcNotify would carry a LABEL-CONTROLS-SPACE-TLV wh= ich contains both existing and new ranges and not build in add/remove/diff = semantics inside of the TLV itself.

=C2=A0

Thanks

Andrew

=C2=A0

From: Cheng Li <c.l=3D40huawei.com@dmarc.ietf.org>
Date: Tuesday, July 9, 2024 at 6:28 AM
To: Dhruv Dhody <dd@dhruvdhody.com>
Cc: pce@ietf.org <pce@ietf.org&g= t;, pce-chairs <pce-chairs@ietf.org>, Samuel Sidor (ssidor) <ssidor@cisco.com>
Subject: RE: [Pce] Where the Controlled ID info shuold be carried/en= coded?

=C2= =A0

CAUTION: This is an external email. Please be very = careful when clicking links or opening attachments. See the URL nok.it/ext= for additional information.

=C2=A0

Yes, I also think this combination is better.

Option 1 Open msg can be used for initial report, and the = rest update can be reported by the Notification msg.

=C2=A0=

Already recorded this in the slide.

=C2=A0=

Cheng<= /span>

=C2=A0=

=C2=A0=

From: Dhruv Dhody <dd@dhruvdhody.c= om>
Sent: Tuesday, July 9, 2024 11:34 AM
To: Cheng Li <c.l@huawei.com>
Cc: pce@ietf.org; pce-chairs <pce-chairs@ietf.org>; Samuel Sidor (ssidor) <ssidor@cisco.com>
Subject: Re: [Pce] Where the Controlled ID info shuold be carried/en= coded?

=C2=A0=

Hi,=C2=A0

=C2=A0<= span style=3D"font-size:12pt">

Samuel made a = suggestion to combine the options of using Open and Notification together, = I have now captured that in the notes page -=C2=A0https= ://notes.ietf.org/draft-ietf-pce-controlled-id-space?view=C2=A0=

=C2=A0<= span style=3D"font-size:12pt">

Feel free to a= dd to the discussion here or on the notes page.=C2=A0

=C2=A0<= span style=3D"font-size:12pt">

Thanks!=C2=A0<= /span>

Dhruv

=C2=A0=

On Sat= , Jul 6, 2024 at 2:53=E2=80=AFPM Dhruv Dhody <dd@dhruvdhody.com<= /a>> wrote:

Hi Cheng,=C2= =A0

=C2=A0<= span style=3D"font-size:12pt">

=C2=A0<= span style=3D"font-size:12pt">

WG,=C2=A0

=C2=A0<= span style=3D"font-size:12pt">

Feel free to a= dd things there but add your name for easy tracking.=C2=A0

You can also a= dd your preference for a solution and with reasoning at the bottom or simpl= y reply on this=C2=A0thread and I can keep the notes page updated.=C2=A0

=C2=A0<= span style=3D"font-size:12pt">

Hope the WG fi= nds this useful and it helps in converging=C2=A0on a way forward...=C2=A0

=C2=A0<= span style=3D"font-size:12pt">

Thanks!=C2=A0<= /span>

Dhruv

=C2=A0=

On Thu= , Jun 20, 2024 at 10:46=E2=80=AFAM Cheng Li <c.l=3D40huawei.com= @dmarc.ietf.org>= ; wrote:

Hi Guys=EF=BC=8C

=C2=A0

Thank you so much for your helpful review and comments of our= draft draft-ietf-pce-controlled-id-space.=C2=A0

In the WG adoption, I can summarize our discussion into the b= elow bullets, hope they are correct,<= u>

  1. The draft is useful, and the mechanism defined in = the draft is needed, we should work on it. (Thanks!)
  2. We need t= o discuss the where the info should be carried in the PCEP. Open Object see= ms not so good =E2=98=B9<= u>
  3. TLV encoding should be updated t= o be more generic or let's avoid the generic description and define spe= cific sub-TLVs as needed.
    4. =

=C2=A0

I see the reasons why we decided to carry the info in PCEP Op= en Object, because it is a device-wide configuration info, which should not= be modified in the running state. We= may face a lot of trouble of removing some IDs and then modify the range in a= running network. However, we may also need to handle the negotiation betwe= en PCC and PCE?=C2=A0 Therefore, I am also concerning about this.

=C2=A0

I like to hear your voice on this, which object/msg is approp= riate to carry the info? I am open with other options.

=C2=A0

Possible options could be

l=C2= =A0 Open message

l=C2= =A0 Use PCEP-LS encod= ing and make this a node attribute

l=C2= =A0 New type of notif= ication

l=C2= =A0 New message/objec= t

=C2=A0

Once we get the conclusion of this, we can go to the bullet 3= , which is much easier that bullet 2. IMHO, I will prefer to define sub-TLV= s one by one, this can decouple the relations between IDs, though we may need to delete the &= #39;generic' words.=

=C2=A0

Thoughts?=

Cheng

=C2=A0=

______= _________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-leave= @ietf.org

--000000000000dedb29061e73d988--