Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC10C1DC81D for ; Wed, 29 Jan 2025 16:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xGrGEegraaHz for ; Wed, 29 Jan 2025 16:44:37 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 405E0C1DC80E for ; Wed, 29 Jan 2025 16:44:37 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5d3bbb0f09dso323747a12.2 for ; Wed, 29 Jan 2025 16:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738197876; x=1738802676; 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=u1rTu/L9YnIJkv8sN7RTvmxT44umcNe4P7mPBkcF32c=; b=Ch6vK375xnX5alk9rqVvJdqcMpIK4m0+eELiX7wwWmieAaJBeLKB09J9WHEoYafhTO 4S6W0j6o5miDl9Gt1jx0jX1ECjelnTOwMTsYHiYCQl8GfnGSbrXVEPZhNM2v7YCeih3b 3Guia8ZyfjtQkujb0WOZEdSB2VwSCPd9fk/gIFbXzpC50+93sDmu4I5TRCvBt1qmeQM2 dDc96lk7gyEVVb3jbonZMBT4jhR9tTI8AZVaWDXBttAUA9rAL8GXwl3GmQb1yj+NK7lp Wolfp/55L6EP7uGPKr3Zp6sv0RwkAvdGsscWSv3bajpcHRPHzoQkQ7Z1eIr0NXvcqUkf fKKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738197876; x=1738802676; 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=u1rTu/L9YnIJkv8sN7RTvmxT44umcNe4P7mPBkcF32c=; b=H189A2FaPNnktVvgHZaag4DetC6qOp5Z/MS9yoty/hEYLTXfcswtbVpKKP0XS7hUyz V2RT3d6zPXrt1jtErRWHiMMl0CRsSeQYbE05HgZWKTm4aN2PStsjbjYsH9GXCwA3T2Nr 5GM8qPI6B5buA+zNzmGud2FGfzBlo25CyBSy/OanSWQDJYNMk/ZLetrdGvSprvpXl3TF 7wHU6rQTEwX07kld5DrdC0sEHLZRpmqJt0xpEtbJ/pBr7OYDwVgEAnud5JxQ0k24HBev gml3zfJuTnwQaMe65XIrCcy6j9qfRX9s4kRl6RzubNw949RDh/015CvrstN8gcAdrdCj hCFQ== X-Forwarded-Encrypted: i=1; AJvYcCVdCnUqEIIn09YfZRdgEWbnpxYhXDny0UiW4rEM2fMycHRyDbt0HVOi8nx9WBMorvy4Bp1m@ietf.org X-Gm-Message-State: AOJu0YysBXXxQ2ePvbdUHlK4awyfhFqY+mfbGbLdM7dfguFhHa+jVm6Q IAZFYTi9Ro7RnYNeA6VW97A8VnOeOsQ9DNqAzvYXNsHyi2IqWrU3M1n+euYijqXTUGCcUsCuBTg FY7zQqcIXJW2LVN42EbeYBEp4eEo= X-Gm-Gg: ASbGncsZUHYIClYYt5iZa5sAaVHwd5EvgR3qwEpK5Sy5ouyiigMmB/NTzo0yr49Q737 p4QVxaZTsu/o1m4Sc7W6jv5hnUg+KdpiscACbZ/i0NOCpG87NdJYeKEujmWW7+YHp6vh/BBFdrc /XQJnKgIgHPPLmExPE03iu0jjmjyc1DwM= X-Google-Smtp-Source: AGHT+IEm9TJ6FISds6wWlk+EYIoGHM2wPwyR3jAYZOHXxkPBCZg0dd6KTZe2uvdvVNg5McrLim5Jv1olEhCUXUZZtWM= X-Received: by 2002:a05:6402:2550:b0:5dc:545:40a7 with SMTP id 4fb4d7f45d1cf-5dc5efc1c5cmr5420483a12.12.1738197875400; Wed, 29 Jan 2025 16:44:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Wed, 29 Jan 2025 19:44:21 -0500 X-Gm-Features: AWEUYZk3XPt3udEOMcg-WuAeUEFyRmY_2YYpuptZ_8O7z_XaovXtND6g5IBemLg Message-ID: To: Igor Malyushkin Content-Type: multipart/alternative; boundary="000000000000e9a513062ce1bae4" Message-ID-Hash: JGKUGZD7TNUHVBIUZ4WTWOQZ7Q7IRKMB X-Message-ID-Hash: JGKUGZD7TNUHVBIUZ4WTWOQZ7Q7IRKMB X-MailFrom: hayabusagsm@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Jorge Rabadan (Nokia)" , "Matthew Bocci (Nokia)" , "bess@ietf.org" , "Gunter van de Velde (Nokia)" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bbess=5D_Re=3A_Errata_on_RFC7117_and_RFC8584?= List-Id: BGP-Enabled ServiceS working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000e9a513062ce1bae4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Igor Ditto & me more attentive in reading the draft! Cheers Gyan On Wed, Jan 29, 2025 at 5:56 AM Igor Malyushkin wrote: > Gyan, > > I=E2=80=99m sorry for a mistake with your name. I=E2=80=99ll be more atte= ntive next time! > > =D0=A1=D1=80, 29 =D1=8F=D0=BD=D0=B2. 2025=E2=80=AF=D0=B3. =D0=B2 17:04, I= gor Malyushkin : > >> >> Hi Gian, >> >> Section 9.2.2 cannot be applied, it says that explicitly: >> >> Usage of leaf A-D routes is described in the "*Inter-AS* Inclusive >> P-Multicast Tree A-D/Binding" and "Optimizing Multicast Distribution >> via Selective Trees" sections. >> >> >> The section in question is named "*Intra-AS* Inclusive P-Multicast Tree >> Auto-discovery/Binding", not *Inter*. Please, pay attention to it. >> >> At the same time, Sections 4 and 4.1 describe which routes they exactly >> expect: >> >> VPLS auto-discovery using BGP, as described in [RFC4761 ] and >> [RFC6074 ], enables a PE to l= earn the VPLS instance membership of >> other PEs. >> >> >> And: >> >> To participate in the VPLS auto-discovery/binding, a PE router that >> has a given VSI of a given VPLS instance originates a BGP VPLS Intra- >> AS A-D route and advertises this route in Multiprotocol (MP) IBGP. >> The route is constructed as described in [RFC4761 ] and [RFC6074 ]. >> >> >> These must be VPLS A-D routes, not Leaf routes, and they don't have an >> Originating Router IP field. >> >> ... then the local PE MUST use the >> Originating Router's IP Address information carried in the *Intra-AS >> A-D route* to add the PE, that originated the route, as a leaf node t= o >> the LSP. This MUST be done irrespective of whether or not the >> received Intra-AS A-D route carries the PMSI Tunnel attribute. >> >> >> In my understanding, a "leaf" above is specifically *for the RSVP-TE* *c= ase >> *when a sending PE can't expect any actual leaf routes from others >> because of the nature of *inclusive *tree construction and it still >> needs to signal tunnels toward them (thus, needs to know their addresses= ). >> >> So, I still think the errata is correct. >> >> P.S. I don't like the idea of using the BGP NH as an identifier of a >> sender. I think the IETF should provide better tools for that case (as w= ell >> as for the case of the identification of a service instance from a sende= r). >> But this is out-of-scope and cannot be applied right here for the proble= m >> in question, so BGP NH is the only option. >> >> >> >> >> =D1=81=D1=80, 29 =D1=8F=D0=BD=D0=B2. 2025=E2=80=AF=D0=B3. =D0=B2 14:10, = Gyan Mishra : >> >>> >>> Hi Jorge >>> >>> I reviewed the errata. >>> >>> For the RFC 7117 errata I had a question. >>> >>> Notes: >>> >>> There is no such field as the Origination Router's IP Address in any >>> VPLS A-D routes (RFC4761, RFC6074). For Intra-AS cases the BGP NH IP >>> address can be used for the leaf tracking. >>> Section 9.2,2 describes the VPLS Leaf A-D route which has route key and >>> originating routers IP address that the source sends Leaf A-D for S-PMS= i >>> w/o PTA attribute present. >>> >>> RFC 6514 procedure uses the same leaf a-d route for mLDP P2MP of RSVP-T= E >>> P2MP PTA described in section 4.4 for lead a-d route. >>> >>> To me it seems the text is correct in RFC 7117. >>> >>> The other errata is correct for RFC 8584. >>> >>> >>> Kind Regards >>> >>> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions A**rchitect * >>> >>> *Email gyan.s.mishra@verizon.com * >>> >>> >>> >>> *M 301 502-1347* >>> >>> >>> >>> On Tue, Jan 28, 2025 at 9:24 AM Jorge Rabadan (Nokia) >> 40nokia.com@dmarc.ietf.org> wrote: >>> >>>> Hi Matthew, >>>> >>>> I checked the two errata and I agree they are correct. >>>> Thanks. >>>> Jorge >>>> >>>> From: Matthew Bocci (Nokia) >>>> Date: Monday, January 27, 2025 at 3:17=E2=80=AFAM >>>> To: bess@ietf.org >>>> Cc: Gunter van de Velde (Nokia) >>>> Subject: [bess] Errata on RFC7117 and RFC8584 >>>> >>>> WG >>>> >>>> >>>> >>>> There are a couple of errata on these RFCs that I would appreciate you= r >>>> feedback on: >>>> >>>> >>>> >>>> https://www.rfc-editor.org/errata_search.php?eid=3D7977 (Multicast in >>>> Virtual Private LAN Service (VPLS)) >>>> >>>> - I believe this is correct and can be verified. >>>> >>>> >>>> >>>> https://www.rfc-editor.org/errata_search.php?eid=3D5900 (Framework for >>>> Ethernet VPN Designated Forwarder Election Extensibility) >>>> >>>> - I believe this is correct and can be verified. >>>> >>>> >>>> >>>> Please let me know by Monday 10th Feb if you have any concerns with >>>> verifying these. >>>> >>>> >>>> >>>> Best regards >>>> >>>> >>>> >>>> Matthew >>>> _______________________________________________ >>>> BESS mailing list -- bess@ietf.org >>>> To unsubscribe send an email to bess-leave@ietf.org >>>> >>> _______________________________________________ >>> BESS mailing list -- bess@ietf.org >>> To unsubscribe send an email to bess-leave@ietf.org >>> >> --000000000000e9a513062ce1bae4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Igor=C2=A0

=
Ditto & me more attenti= ve in reading the draft!

Cheers=C2=A0

Gyan
=

On Wed, Jan 29, 2025 at 5:56 AM Igor Malyushkin <gmalyushkin@gmail.com> wrote:=
Gyan,

I=E2=80=99m sorry for a mistake wi= th your name. I=E2=80=99ll be more attentive next time!

=D0=A1=D1=80, 29 =D1=8F=D0=BD=D0=B2. 202= 5=E2=80=AF=D0=B3. =D0=B2 17:04, Igor Malyushkin <gmalyushkin@gmail.com>:

Hi Gian,

Section 9.2.2 cannot= be applied, it says that explicitly:

   Usage of leaf A-D routes is described in the "<=
b style=3D"font-family:monospace">Inter-AS Inclusive
   P-Multicast Tree A-D/Binding" and "Optimizing Multicast Distri=
bution
   via Selective Trees" sections.

The section in question is = named "Intra-AS Inclusive P-Multicast Tree Auto-discovery/Bindi= ng", not Inter. Please, pay attention to it.

At the same= =C2=A0time, Sections 4 and 4.1 describe which routes they exactly expect:
   VPLS auto-discov=
ery using BGP, as described in [RFC4761] and
   [RFC6074], enables a PE to learn the VPLS instance membership of
   other PEs.

And:

   To participate in the VPLS auto-discovery/binding, a PE route=
r that
   has a given VSI of a given VPLS instance originates a BGP VPLS Intra-
   AS A-D route and advertises this route in Multiprotocol (MP) IBGP.
   The route is constructed as described in [RFC4761] and [RFC6074].

These must be VPLS A-D routes, not Leaf routes, and they don'= t have an Originating Router IP field.

   ... then the local PE MUST use the
   Originating Router's IP Address information carried in the Intra-AS
   A-D route to add the PE, that originated the route, as a leaf node t=
o
   the LSP.  This MUST be done irrespective of whether or not the
   received Intra-AS A-D route carries the PMSI Tunnel attribute.

= In my understanding, a "leaf" above is specifically for the RS= VP-TE case when a sending PE can't expect any actual leaf ro= utes from others because of the nature of inclusive tree constructio= n and it still needs to signal tunnels toward them (thus, needs to know the= ir addresses).

So, I still think the errata is correct.

P.S. = I don't like the idea of using=C2=A0the BGP NH as an identifier of a se= nder. I think the IETF should provide better tools for that case (as well a= s for the case of the identification of a service instance from a sender). = But this is out-of-scope and cannot be applied right here for the problem i= n question, so BGP NH is the only option.




=D1=81=D1=80= , 29 =D1=8F=D0=BD=D0=B2. 2025=E2=80=AF=D0=B3. =D0=B2 14:10, Gyan Mishra <= ;hayabusagsm@gma= il.com>:
=

Hi Jorge=C2=A0
<= br>
I reviewed the errata.
For the RFC 7117 errata I had a question.

Notes:

There is no such field as the Origination Router's IP Ad= dress in any VPLS A-D routes (RFC4761, RFC6074). For Intra-AS cases the BGP= NH IP address can be used for the leaf tracking.

Section 9.2,2 de= scribes the VPLS Leaf A-D route which has route key and originating routers= IP address that the source sends Leaf A-D for S-PMSi w/o PTA attribute pre= sent.

RFC 6514 procedure= uses the same leaf a-d route for mLDP P2MP of RSVP-TE P2MP PTA described i= n section 4.4 for lead a-d route.

To me it seems the text is correct in RFC 7117.

The other errata is correct for RFC 8584.=


Kind Regards=C2=A0

<= /div>

On Tue, Jan 28, 2025 at 9:24 AM Jorge Rabadan (Nokia) <jorge.rabadan= =3D40nokia.= com@dmarc.ietf.org> wrote:
Hi Matthew,

I checked the two errata and I agree they are correct.
Thanks.
Jorge

From: Matthew Boc= ci (Nokia) <matthew.bocci=3D40nokia.com@dmarc.ietf.org<= /a>>
Date: Monday, Jan= uary 27, 2025 at 3:17=E2=80=AFAM
To: bess@ietf= .org <bess@ietf.org>
Cc: Gunter van de= Velde (Nokia) <gunter.van_de_velde@nokia.com&= gt;
Subject: [bess] E= rrata on RFC7117 and RFC8584

WG

=C2=A0

There are a cou= ple of errata on these RFCs that I would appreciate your feedback on:

=C2=A0

https://www.rfc-editor.org/errata_search.php?eid= =3D7977 (Multicast in Virtual Private LAN Service (VPLS))

  • I believe this = is correct and can be verified.

=C2=A0

https://www.rfc-editor.org/errata_search.php?eid= =3D5900 (Framework for Ethernet VPN Designated Forwarder Election Exten= sibility)

  • I believe this is correct and can be verified.

=C2=A0

Please let me know by Monday 10= th Feb if you have any concerns with verifying these.

=C2=A0

Best regards

=C2=A0

Matthew

_______________________________________________
BESS mailing list -- bes= s@ietf.org
To unsubscribe send an email to bess-leave@ietf.org
_______________________________________________
BESS mailing list -- bes= s@ietf.org
To unsubscribe send an email to bess-leave@ietf.org
--000000000000e9a513062ce1bae4--