IETF Logo Mail Archive

Re: [bess] I-D Action: draft-ietf-bess-srv6-services-13.txt

Joel Halpern Direct <jmh.direct@joelhalpern.com> Mon, 21 March 2022 10:39 UTC

Return-Path: <jmh.direct@joelhalpern.com>
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 6AC773A0D62 for <bess@ietfa.amsl.com>; Mon, 21 Mar 2022 03:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4vlDO0aly3k for <bess@ietfa.amsl.com>; Mon, 21 Mar 2022 03:38:58 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03E63A1A33 for <bess@ietf.org>; Mon, 21 Mar 2022 03:38:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4KMWLb3f7bz1ntcR; Mon, 21 Mar 2022 03:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1647859127; bh=DXbaD0a7wg9p0HU4D3XQpXklzObPTjj5W4MIULDNAMc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=LjjpPDIc65Cy06Jge1c3BPU5AEhuUuDqM76a1QmcISLQDJJ1NJ2Wo9iIEMY1FsLl+ bgdB3pGAPhXr9scJmyGTPoICU/MllA0Q7j1VhGjuLCOJoIZN23rPbS/mF0UpTLbx34 pcqb1pgkhJtMcFz5qcpOcNZIOYVmAR7h9KnrmIc8=
X-Quarantine-ID: <Bk5GHI6KhvvJ>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.21.218] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4KMWLZ6htZz1nsTB; Mon, 21 Mar 2022 03:38:46 -0700 (PDT)
Message-ID: <9d4cd776-f64b-9bcb-8804-c9d821755ea4@joelhalpern.com>
Date: Mon, 21 Mar 2022 06:38:45 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: BESS <bess@ietf.org>
References: <164774714961.16649.7874978579378917523@ietfa.amsl.com> <afa17ecf-3345-6756-637c-d4917861563b@joelhalpern.com> <CAH6gdPwgdvDo9oFFYef5B8OWwtrv=22RPW3cF1j2BLNo6+X1yw@mail.gmail.com> <270f23a8-6d29-28c5-1669-37029e908f59@joelhalpern.com> <CAH6gdPxdbUa1QAzhW8aYT8PBeHgNcatZGzhugswyPLhB146oCA@mail.gmail.com> <67a0923b-2e03-e7b7-ffad-9bab2d7606f8@joelhalpern.com> <CAH6gdPyH1SP26VG8jcv9A__nrDRnAHv7xTPP_hdyENKQ+9MLAQ@mail.gmail.com> <cfffc570-d002-71c1-f365-f0374474e944@joelhalpern.com> <CAH6gdPx90DojzfVhrE57Ri0wZm-e1YHBnd=SCQ8vYfdtEV560A@mail.gmail.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
In-Reply-To: <CAH6gdPx90DojzfVhrE57Ri0wZm-e1YHBnd=SCQ8vYfdtEV560A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/tWFeZWNng0hZpcFe_I6jYxA3ucM>
Subject: Re: [bess] I-D Action: draft-ietf-bess-srv6-services-13.txt
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 10:39:11 -0000

In line.

On 3/21/2022 6:30 AM, Ketan Talaulikar wrote:
> Hi Joel,
> 
> Please check inline below.
> 
> 
> On Mon, Mar 21, 2022 at 2:19 PM Joel M. Halpern <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> wrote:
> 
>     Okay, so for all cases where the argument length is non-zero, the
>     receiver can use the advertisement only if they understand the behavior?
> 
> 
> KT> Yes.
> 
> 
>     What does it mean for the receiver to "use" the behavior when the
>     argument length is zero? 
> 
> 
> KT> "Use" would be to put the SRv6 Service SID received from the egress 
> PE via BGP signaling as the IPv6 DA on the outer IPv6 encapsulation 
> introduced on the ingress PE and routing this encapsulated packet 
> towards the egress PE.

that was the use I had understood was intended by the draft.  What I do 
not see is any way that the endpoint behavior (and / or the 
understanding or lack of understanding thereof) makes any difference.

> 
>     What can the receiver do differently based on
>     understanding the endpoint behavior?
> 
> 
> KT> The draft does not specify anything in this regard.

I was prompted to ask this by wondering,, if the behavior could matter, 
if the receiver did not understand the behavior, how could it know there 
was a problem.  If this is strictly tied to the argument length being 
non-zero, then I can at least understand it.

If there is some other case, then there appears to be a determinancy 
problem.   I suspect his could be resolved by having the sender only use 
a behavior other than 0xFFFF if the SID can only be used by an Ingress 
who understand the specified (non 0xFFF) behavior??

Yours,
Joe;

> 
> 
>     Yours,
>     Joel
> 
>     PS: By "transport" I was (sloppily, sorry) referring to the
>     transposition mechanism, which seemed to be defined by the argument
>     length, transposition offset, and the route type.  From what you say,
>     that does not suffice to fill in the argument field.  If so, the
>     exposition in the draft should be improved.
> 
> 
> KT> The transposition scheme is limited to the BGP encoding alone and 
> not related to the rest of the functionality. Perhaps I am still not 
> getting your point here?
> 
> Thanks,
> Ketan
> 
> 
>     On 3/21/2022 4:41 AM, Ketan Talaulikar wrote:
>      > Hi Joel,
>      >
>      > Please check inline below.
>      >
>      >
>      > On Sun, Mar 20, 2022 at 11:13 PM Joel Halpern Direct
>      > <jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>
>     <mailto:jmh.direct@joelhalpern.com
>     <mailto:jmh.direct@joelhalpern.com>>> wrote:
>      >
>      >     I have reread the draft.  let me try asking the quesiton the
>      >     opposite way.
>      >
>      >     1) If the argument length is zero, then an Ingress PE will always
>      >     ignore
>      >     the SRv6 Endpoint behavior, as it will not do anything
>     differently
>      >     if it
>      >     understands or does not understand the behavior.
>      >
>      >
>      > KT> The draft does not say that the behavior is to be ignored. It
>     says
>      > that ingress PE can still use such behaviors even if they are
>      > unknown/unsupported.
>      >
>      >
>      >     2) If the argument length is non-zero, but it is being filled
>     in by the
>      >     transportion mechanism, then again the Ingress PE might as
>     well ignore
>      >     the SRv6 Endpoint Behavior Information
>      >
>      >
>      > KT> RFC8986 does not talk about any behavior where the argument is
>      > filled by the transport mechanism. Neither does this draft.
>      >
>      >
>      >     3) If other information such as the use of the MPLS ESI or
>     label (EVPN
>      >     Auto-Discovery) is used to fill in the argument, this is
>     determined
>      >     from
>      >     the type information and not from the SRv6 Endpoint Behavior?
>      >
>      >
>      > KT> Just the route type information is not sufficient and
>     understanding
>      > of the behavior is also required before it can be used.
>      >
>      >
>      >     4) If none of those cases apply, and the SRv6 Endpoint
>     Behavior is
>      >     known
>      >     by the Ingress PE, and that behavior reuries other
>     manipulation of the
>      >     argument field of the resulting SID, then the Ingress PE acts
>     on that
>      >     information?  And the advertiser has to somehow ensure that all
>      >     receivers will correctly understand the necessary manipulation?
>      >
>      >
>      >     It seems that carrying the SRv6 Endpoint Behavior, and trying to
>      >     describe when it needs to be understood, is for a use case
>     that is not
>      >     even covered in the document?
>      >
>      >
>      > KT> I am not sure that I understand the above two paragraphs very
>     well.
>      > For any behavior where arguments are used, the
>     understanding/support for
>      > the behavior is required at the ingress PE - to set the argument
>     part of
>      > the SID before sending the packets towards the egress PE. Where
>      > arguments are not used, the SID can be used, as signaled, by the
>     ingress
>      > PE even if it does not understand the behavior.
>      >
>      > Thanks,
>      > Ketan
>      >
>      >
>      >     Yours,
>      >     Joel
>      >
>      >     On 3/20/2022 2:54 AM, Ketan Talaulikar wrote:
>      >      > Hi Joel,
>      >      >
>      >      > Please see inline below.
>      >      >
>      >      > On Sun, Mar 20, 2022 at 11:34 AM Joel M. Halpern
>      >     <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>      >      > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>> wrote:
>      >      >
>      >      >     I seem to be missing something.
>      >      >
>      >      >     The ingress PE (domain edge) applies the destination SID
>      >     (possibly as
>      >      >     part of a SID list).  Either it is deciding to use the
>      >     destination SID,
>      >      >     or something else is deciding to use the destination SID.
>      >      >
>      >      >
>      >      > KT> The ingress PE is deciding. Something else (e.g., a
>      >     controller) may
>      >      > decide the path (e.g., SID list for SR Policy) but the
>     Service/VPN
>      >      > context is signaled via BGP from egress to ingress PE.
>      >      >
>      >      >
>      >      >     Ignoring the issue of argument manipulation, if the
>     Ingress PE is
>      >      >     deciding on its own, doesn't it have to understand the
>      >     meaning of the
>      >      >     behavior in order to decide that it wants to invoke it?
>      >      >
>      >      >
>      >      > KT> The ingress PE is not invoking anything and hence it
>     doesn't
>      >     need to
>      >      > understand the meaning of the behavior (with some
>     exceptions like
>      >     when
>      >      > it needs to supply the argument). Ingress PE is simply
>     setting the
>      >      > received SRv6 Service SID as the IPv6 DA in the outer
>     encapsulation
>      >      > (let's keep aside SR Policy for now). When this packet
>     reaches the
>      >      > egress PE, it ends up invoking the behavior corresponding
>     to the
>      >     locally
>      >      > instantiated SRv6 SID on the egress PE. As an analogy -
>     whether the
>      >      > label signaled by the egres PE is per-VRF or per-CE does not
>      >     affect the
>      >      > processing at ingress PE.
>      >      >
>      >      >     If something else provides the SID list and the rules for
>      >     which traffic
>      >      >     should use it (e.g. the SR policy or similar) then the
>      >     Ingress PE would
>      >      >     not seem to need such understanding.
>      >      >
>      >      >
>      >      > KT> The situation is the same even in this case.
>      >      >
>      >      > Thanks,
>      >      > Ketan
>      >      >
>      >      >
>      >      >     Yours,
>      >      >     Joel
>      >      >
>      >      >     On 3/20/2022 1:37 AM, Ketan Talaulikar wrote:
>      >      >      > Hi Joel,
>      >      >      >
>      >      >      > There is no implicit assumption such as the one you
>     refer
>      >     to. The
>      >      >      > ingress PE does not need to do anything specific
>     with the
>      >     choice
>      >      >     of the
>      >      >      > behavior picked by the egress PE except where the
>     behavior
>      >      >     involves the
>      >      >      > use of argument. Ingress PE does need to know & support
>      >     the specific
>      >      >      > behavior when it needs to supply the argument based
>     on the
>      >     behavior
>      >      >      > definition.
>      >      >      >
>      >      >      > Thanks,
>      >      >      > Ketan
>      >      >      >
>      >      >      > On Sun, Mar 20, 2022 at 10:56 AM Joel M. Halpern
>      >      >     <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>      >     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>
>      >      >      > <mailto:jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com>>
>      >     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>     <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>>> wrote:
>      >      >      >
>      >      >      >     I keep reading the description of the handling
>     of unknown
>      >      >     endpoint
>      >      >      >     behaviors.
>      >      >      >
>      >      >      >     It seems there is an implicit assumption that I
>     would
>      >     think
>      >      >     it would be
>      >      >      >     helpful to make explicit.  As far as I can tell, a
>      >     head end
>      >      >     would never
>      >      >      >     choose based purely based on local policy to
>     make use
>      >     of an
>      >      >     advertised
>      >      >      >     SID with an unknown behavior?  However, a head end
>      >     might use
>      >      >     such a
>      >      >      >     ISD,
>      >      >      >     without knowing what it was really asking, if so
>      >     instructed
>      >      >     by a policy
>      >      >      >     engine (e.g. SR Policy)?
>      >      >      >
>      >      >      >     Yours,
>      >      >      >     Joel
>      >      >      >
>      >      >      >     On 3/19/2022 11:32 PM, internet-drafts@ietf.org
>     <mailto:internet-drafts@ietf.org>
>      >     <mailto:internet-drafts@ietf.org
>     <mailto:internet-drafts@ietf.org>>
>      >      >     <mailto:internet-drafts@ietf.org
>     <mailto:internet-drafts@ietf.org>
>      >     <mailto:internet-drafts@ietf.org
>     <mailto:internet-drafts@ietf.org>>>
>      >      >      >     <mailto:internet-drafts@ietf.org
>     <mailto:internet-drafts@ietf.org>
>      >     <mailto:internet-drafts@ietf.org
>     <mailto:internet-drafts@ietf.org>>
>      >      >     <mailto:internet-drafts@ietf.org
>     <mailto:internet-drafts@ietf.org>
>      >     <mailto:internet-drafts@ietf.org
>     <mailto:internet-drafts@ietf.org>>>> wrote:
>      >      >      >      >
>      >      >      >      > A New Internet-Draft is available from the
>     on-line
>      >      >      >     Internet-Drafts directories.
>      >      >      >      > This draft is a work item of the BGP Enabled
>      >     ServiceS WG
>      >      >     of the IETF.
>      >      >      >      >
>      >      >      >      >          Title           : SRv6 BGP based
>     Overlay
>      >     Services
>      >      >      >      >          Authors         : Gaurav Dawra
>      >      >      >      >                            Clarence Filsfils
>      >      >      >      >                            Ketan Talaulikar
>      >      >      >      >                            Robert Raszuk
>      >      >      >      >                            Bruno Decraene
>      >      >      >      >                            Shunwan Zhuang
>      >      >      >      >                            Jorge Rabadan
>      >      >      >      >       Filename        :
>      >     draft-ietf-bess-srv6-services-13.txt
>      >      >      >      >       Pages           : 34
>      >      >      >      >       Date            : 2022-03-19
>      >      >      >      >
>      >      >      >      > Abstract:
>      >      >      >      >     This document defines procedures and
>     messages for
>      >      >     SRv6-based BGP
>      >      >      >      >     services including L3VPN, EVPN, and Internet
>      >     services.  It
>      >      >      >     builds on
>      >      >      >      >     RFC4364 "BGP/MPLS IP Virtual Private
>     Networks
>      >     (VPNs)"
>      >      >     and RFC7432
>      >      >      >      >     "BGP MPLS-Based Ethernet VPN".
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > The IETF datatracker status page for this
>     draft is:
>      >      >      >      >
>      >      >
>     https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
>      >   
>       <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>>
>      >      >
>      >     
>       <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
>      >   
>       <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>>>
>      >      >      >
>      >      >
>      >     
>       <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
>      >   
>       <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>>
>      >      >
>      >     
>       <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>
>      >   
>       <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/>>>>
>      >      >      >      >
>      >      >      >      > There is also an htmlized version available at:
>      >      >      >      >
>      >      >      >
>      >      >
>      >
>     https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13
>     <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>
>      >   
>       <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>>
>      >      >
>      >     
>       <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>>>
>      >      >      >
>      >      >
>      >     
>       <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13>>>>
>      >      >      >      >
>      >      >      >      > A diff from the previous version is
>     available at:
>      >      >      >      >
>      >      >      >
>      >      >
>      >
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13
>     <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>
>      >   
>       <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>>
>      >      >
>      >     
>       <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13> <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>>>
>      >      >      >
>      >      >
>      >     
>       <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13> <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>> <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13> <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-13>>>>
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > Internet-Drafts are also available by rsync at
>      >      >      >     rsync.ietf.org::internet-drafts
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > _______________________________________________
>      >      >      >      > I-D-Announce mailing list
>      >      >      >      > I-D-Announce@ietf.org
>     <mailto:I-D-Announce@ietf.org>
>      >     <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>>
>     <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>      >     <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>>>
>      >      >     <mailto:I-D-Announce@ietf.org
>     <mailto:I-D-Announce@ietf.org> <mailto:I-D-Announce@ietf.org
>     <mailto:I-D-Announce@ietf.org>>
>      >     <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>     <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>>>>
>      >      >      >      >
>     https://www.ietf.org/mailman/listinfo/i-d-announce
>     <https://www.ietf.org/mailman/listinfo/i-d-announce>
>      >     <https://www.ietf.org/mailman/listinfo/i-d-announce
>     <https://www.ietf.org/mailman/listinfo/i-d-announce>>
>      >      >     <https://www.ietf.org/mailman/listinfo/i-d-announce
>     <https://www.ietf.org/mailman/listinfo/i-d-announce>
>      >     <https://www.ietf.org/mailman/listinfo/i-d-announce
>     <https://www.ietf.org/mailman/listinfo/i-d-announce>>>
>      >      >      >   
>       <https://www.ietf.org/mailman/listinfo/i-d-announce
>     <https://www.ietf.org/mailman/listinfo/i-d-announce>
>      >     <https://www.ietf.org/mailman/listinfo/i-d-announce
>     <https://www.ietf.org/mailman/listinfo/i-d-announce>>
>      >      >     <https://www.ietf.org/mailman/listinfo/i-d-announce
>     <https://www.ietf.org/mailman/listinfo/i-d-announce>
>      >     <https://www.ietf.org/mailman/listinfo/i-d-announce
>     <https://www.ietf.org/mailman/listinfo/i-d-announce>>>>
>      >      >      >      > Internet-Draft directories:
>      >      > http://www.ietf.org/shadow.html
>     <http://www.ietf.org/shadow.html> <http://www.ietf.org/shadow.html
>     <http://www.ietf.org/shadow.html>>
>      >     <http://www.ietf.org/shadow.html
>     <http://www.ietf.org/shadow.html> <http://www.ietf.org/shadow.html
>     <http://www.ietf.org/shadow.html>>>
>      >      >      >     <http://www.ietf.org/shadow.html
>     <http://www.ietf.org/shadow.html>
>      >     <http://www.ietf.org/shadow.html
>     <http://www.ietf.org/shadow.html>>
>      >      >     <http://www.ietf.org/shadow.html
>     <http://www.ietf.org/shadow.html>
>      >     <http://www.ietf.org/shadow.html
>     <http://www.ietf.org/shadow.html>>>>
>      >      >      >      > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>      >     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>
>      >      >     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>      >     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>>
>      >      >      >     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>      >     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>
>      >      >     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>      >     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>>>
>      >      >      >
>      >      >      >     _______________________________________________
>      >      >      >     BESS mailing list
>      >      >      > BESS@ietf.org <mailto:BESS@ietf.org>
>     <mailto:BESS@ietf.org <mailto:BESS@ietf.org>> <mailto:BESS@ietf.org
>     <mailto:BESS@ietf.org>
>      >     <mailto:BESS@ietf.org <mailto:BESS@ietf.org>>>
>     <mailto:BESS@ietf.org <mailto:BESS@ietf.org> <mailto:BESS@ietf.org
>     <mailto:BESS@ietf.org>>
>      >      >     <mailto:BESS@ietf.org <mailto:BESS@ietf.org>
>     <mailto:BESS@ietf.org <mailto:BESS@ietf.org>>>>
>      >      >      > https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>
>      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>>
>      >      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>
>      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>>>
>      >      >      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>
>      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>>
>      >      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>
>      >     <https://www.ietf.org/mailman/listinfo/bess
>     <https://www.ietf.org/mailman/listinfo/bess>>>>
>      >      >      >
>      >      >
>      >
>

v2.31.3 | Report a Bug | By Email | System Status