Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

Adrian Farrel <adrian@olddog.co.uk> Thu, 25 February 2021 21:53 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501FD3A0C38; Thu, 25 Feb 2021 13:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 G_dpG5HtQVsJ; Thu, 25 Feb 2021 13:53:37 -0800 (PST)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 E556A3A0C49; Thu, 25 Feb 2021 13:53:36 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11PLrWIr003117; Thu, 25 Feb 2021 21:53:32 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 061CE2203B; Thu, 25 Feb 2021 21:53:32 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id E3EAE2203A; Thu, 25 Feb 2021 21:53:31 +0000 (GMT)
Received: from LAPTOPK7AS653V ([84.93.2.163]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11PLrUm0024603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Feb 2021 21:53:30 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'John E Drake' <jdrake=40juniper.net@dmarc.ietf.org>, 'Stewart Bryant' <stewart.bryant@gmail.com>
Cc: 'mpls' <mpls@ietf.org>, int-area@ietf.org, 'Kireeti Kompella' <kireeti@juniper.net>, 'Ron Bonica' <rbonica@juniper.net>, rtg-ads@ietf.org, pals@ietf.org, "'Jeffrey (Zhaohui) Zhang'" <zzhang=40juniper.net@dmarc.ietf.org>
References: <MN2PR05MB59813CFC28F62CC076364991D4AA0@MN2PR05MB5981.namprd05.prod.outlook.com> <F30F0C17-39A6-4D43-AC94-727BC2C9EEC4@gmail.com> <MN2PR05MB59817B1DBD97C4CDEAFF6CDBD4849@MN2PR05MB5981.namprd05.prod.outlook.com> <MN2PR05MB59816A0683CD84266BDB2059D4849@MN2PR05MB5981.namprd05.prod.outlook.com> <F09BD015-3AC2-4A07-9EAE-DCD2DC00D418@gmail.com> <MN2PR05MB5981E6ECADE8A4EACF446C8ED4819@MN2PR05MB5981.namprd05.prod.outlook.com> <ACA96A88-03EF-4BF9-9BB6-24B458148175@gmail.com> <MN2PR05MB598104C61F2C0A862E0A908BD4809@MN2PR05MB5981.namprd05.prod.outlook.com> <MN2PR05MB6623C35CD4D75583F320AD9AC7809@MN2PR05MB6623.namprd05.prod.outlook.com> <60BC74A2-8D94-4011-B77C-3C4830659915@gmail.com> <MN2PR05MB662309742EC653680936A5E2C7809@MN2PR05MB6623.namprd05.prod.outlook.com>
In-Reply-To: <MN2PR05MB662309742EC653680936A5E2C7809@MN2PR05MB6623.namprd05.prod.outlook.com>
Date: Thu, 25 Feb 2021 21:53:30 -0000
Organization: Old Dog Consulting
Message-ID: <004301d70bc0$a83263e0$f8972ba0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01D70BC0.A83745E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEeZV7gI8NQG2nEzMWfbH0cYjhfEQJaETk0AXGuhDABpCXRdwEr/d+QAe8nkjACBfIiQwGa664oAtuhuWYCeQrXtQIfBzunqz24kZA=
Content-Language: en-gb
X-Originating-IP: 84.93.2.163
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25942.003
X-TM-AS-Result: No--15.744-10.0-31-10
X-imss-scan-details: No--15.744-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003
X-TMASE-Result: 10--15.744000-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFp6DVqDv3PkvXFPUrVDm6jtofZV/2Xa0cKV5uE2DDYHnUGz U7CKX1sdKEZ60lyO6rRWGAm8gi2uu6krm8GLHGyoF3wQ0cu1bTNBmlBF/IJ0fEE3/qvOjgFLZWe a/rnq4cXZLoQ7I0lOIj3qh5fQCbKVtEQ7oWt2rQ3jgGDPgcfeORmyTBaqiJvcJvB1W/72qGilKI 4pJ+G9P+CvRZnq77KlQ734gZA71Z6F8C5gzn168PZvT2zYoYOwiRPU6vvejXK+LNysYNiSxIMbT YC6lJG4dUCHbfib2NQPsMiSITv1VWthr6NhZ4Uukr0W/BDHWEXdXhRKGhNdpxbozYDXkvVAmx64 yhYBxccYzGbvuRy4HvwyaAN3oSjvErYGXeikG0UdyHiBnyiVv8gRBOWHX9Ax+32SXw3QiFxnZeM TrZWBRcEdglAiCXqgi5TC6tcabDFP9Oc08XoTFMVUBXy8OM3/caDaLyypNNrkMnUVL5d0EykG/j qIkRKaR6nprnR1P7ax7NcGU1yhwf7EnaDt7cQvkwgo9duuWhdBofiDg/o61iS30GKAkBxWGH4+L kNBL4y/QB8vCn1jLWDekwaXOEu6E1bMeGQU6OAGLRKL2NexjfNkoMDX+kiudQ96pNi3xO+yZz4f MPkeaNpz0yeurlyPIOusie4bRNCrXOKso5Y21n41AgV24XnfIhqpFh0uJwFXJ/NTgaKQpkyC7/z +TOC3KtxInheUvAhHu0HiErCiqOwTP3JxbBsKGLXhwJ3YV6Mr9gVlOIN/6i196sn93sBvpX99ws FdUrhSpFprefCKTFUJYqNxftHdd1HubN56/IWeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7MbNeB9ySxazec3QM3secWZwjmr9ADSqIzJui2aP7sNZN+o4byY6EHjdOjt05c3/lBEtRgLp jr+TUeAh186aceOEbFYOyLsMicytFxBXK7jtQ6C2XZMYa5V+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ylGYEhTeb23oGWVplnkH3uf20vM>
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2021 21:53:41 -0000

> Multiple labels, each with the BoS set, was suggested during the MPLS-TP
days

> (Niel Harrison, in particular, was a big proponent) but was shot down
because it

> would apparently break existing hardware implementations. 

 

Yeah, I was a big fan of that. I even thought it was architecturally the
right thing to do for carrying one MPLS service over an MPLS transport. It
would have solved many of the MPLS-TP requirements.

 

But as John says, lots of hardware then (and probably now) sees bottom of
stack and starts to sniff the next nibble. Thus, contiguous label stacks and
control words were the only viable solution. It took George Swallow a while
to beat this into my head.

 

Cheers,

Adrian

 

Juniper Business Use Only

From: Stewart Bryant <stewart.bryant@gmail.com> 
Sent: Tuesday, February 23, 2021 10:36 AM
To: John E Drake <jdrake@juniper.net>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; Jeffrey (Zhaohui) Zhang
<zzhang=40juniper.net@dmarc.ietf.org>; Rakesh Gandhi
<rgandhi.ietf@gmail.com>; mpls <mpls@ietf.org>; int-area@ietf.org; Kireeti
Kompella <kireeti@juniper.net>; Ron Bonica <rbonica@juniper.net>;
<rtg-ads@ietf.org> <rtg-ads@ietf.org>; pals@ietf.org
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

 

[External Email. Be cautious of content]

 

Having an ACH channel type per set of structures, or a BoS label value per
set of structures would be far more consistent with the MPLS model. 

 

Stewart

 

On 23 Feb 2021, at 15:27, John E Drake <jdrake@juniper.net
<mailto:jdrake@juniper.net> > wrote:

 

Hi,

Why wouldn't we just use GAL/G-ACh for this as it is already a published RFC
that was designed for things like this?   I.e., we could use a GAL and
define families of G-ACh codepoints which describe exactly what is in the
area between the MPLS label stack and the payload.  E.g.,  G-Ach for IOAM:
[value #1 = hop by hop IOAM w/ no subsequent metadata, value #2 = end to end
IOAM w/ no subsequent metadata, value #3 = hop by hop IOAM w/ subsequent
metadata, value #4 = end to end IOAM w/ subsequent metadata].  The
subsequent metadata would then have the same basic structure.

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: mpls <mpls-bounces@ietf.org <mailto:mpls-bounces@ietf.org> > On Behalf
Of Jeffrey (Zhaohui) Zhang
Sent: Tuesday, February 23, 2021 10:19 AM
To: Stewart Bryant <stewart.bryant@gmail.com
<mailto:stewart.bryant@gmail.com> >; Rakesh Gandhi <rgandhi.ietf@gmail.com
<mailto:rgandhi.ietf@gmail.com> >
Cc: mpls <mpls@ietf.org <mailto:mpls@ietf.org> >; int-area@ietf.org
<mailto:int-area@ietf.org> ; Kireeti Kompella <kireeti@juniper.net
<mailto:kireeti@juniper.net> >; Ron Bonica <rbonica@juniper.net
<mailto:rbonica@juniper.net> >; <rtg-ads@ietf.org <mailto:rtg-ads@ietf.org>
> <rtg-ads@ietf.org <mailto:rtg-ads@ietf.org> >; pals@ietf.org
<mailto:pals@ietf.org> 
Subject: Re: [mpls] draft-zzhang-intarea-generic-delivery-functions

 

[External Email. Be cautious of content]

 

Hi Stewart,

 

GDFH has both a "this header" (for a particular function) and a "next
header". One GDFH can point to another GDFH, who could also point to another
header (e.g. MPLS).

 

IOAM could be integrated into GDF. I understand that this is just a thought
and we have not concluded on that yet, but with that thought the headers
would be like the following:

 

   Transport label + GDFH label (BoS) + GDFH (for IOAM) + GDFH (for other
functions not already provided by PW itself) + PW label + PW payload or
G-Ach

 

Depending on the situation, the GDFH (for IOAM) and GDFH (for other
functions) could be swapped. The PW label is essentially another label stack
- the earlier stack stopped at the GDFH label.

 

Now what if IOAM is not integrated into GDF? I see the following in its -06
revision:

    0                   1                   2                   3

    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

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    | IOAM Indicator Label                  | TC  |1|  TTL          |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

    |0 0 0 1|Version| Reserved      | IOAM G-ACh                    |  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |

    | Reserved      | Block Number  | IOAM-OPT-Type |IOAM HDR Length|  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  I

    |                                                               |  O

    |                                                               |  A

    ~                 IOAM Option and Data Space                    ~  M

    |                                                               |  |

    |                                                               |  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

    |0 0 0 1|Version| Reserved      | Channel Type                  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |                                                               |

    |                                                               |

    ~                 Payload + Padding                             ~

    |                                                               |

    |                                                               |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

     Figure 5: Example MPLS Encapsulation with Another G-ACh with IOAM

 

I am not sure if that is a good idea:

 

*	RFC 5586 says "The G-ACh MUST NOT be used to transport user
traffic". To me IOAM traffic is user traffic with OAM information.
*	It puts one G-Ach header after another G-Ach header. As far as I
understand it, G-Ach does not have a "next header" concept and using 0001b
to indicate that another G-Ach header follows is not safe.
*	In case PW payload, the above will put the PW label before the IOAM
label. Having those extra IOAM/G-Ach headers between the PW+IOAM label and
PW payload adds complexity to the fast path processing.

 

Jeffrey

 

From: Stewart Bryant <stewart.bryant@gmail.com
<mailto:stewart.bryant@gmail.com> > 
Sent: Monday, February 22, 2021 7:30 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net <mailto:zzhang@juniper.net>
>
Cc: Stewart Bryant <stewart.bryant@gmail.com
<mailto:stewart.bryant@gmail.com> >; int-area@ietf.org
<mailto:int-area@ietf.org> ; mpls <mpls@ietf.org <mailto:mpls@ietf.org> >;
pals@ietf.org <mailto:pals@ietf.org> ; Kireeti Kompella <kireeti@juniper.net
<mailto:kireeti@juniper.net> >; Ron Bonica <rbonica@juniper.net>;
<rtg-ads@ietf.org <mailto:rtg-ads@ietf.org> > <rtg-ads@ietf.org
<mailto:rtg-ads@ietf.org> >
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

 

[External Email. Be cautious of content]

 

What happens if an operator wants to run both iOAM and GDFH at the same time
and the packet is a PW packet?

 

What does the packet look like and how does the forwarder know what to do?

 

- Stewart

 

On 22 Feb 2021, at 22:49, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net
<mailto:zzhang@juniper.net> > wrote:

 

Hi Stewart,

 

This thread started with your comment "Please see the note that I sent about
iOAM who also want to sit after BoS . and both of you want the same space
that PALS and DetNet is already using", but now it seems that we're on the
same page - GDFH starting with 0000b is fine and is not competing with IOAM
or PW/DETNET CW?

 

Thanks.

Jeffrey

 

From: Stewart Bryant <stewart.bryant@gmail.com
<mailto:stewart.bryant@gmail.com> > 
Sent: Monday, February 22, 2021 5:15 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net <mailto:zzhang@juniper.net>
>
Cc: Stewart Bryant <stewart.bryant@gmail.com
<mailto:stewart.bryant@gmail.com> >; int-area@ietf.org
<mailto:int-area@ietf.org> ; mpls <mpls@ietf.org <mailto:mpls@ietf.org> >;
pals@ietf.org <mailto:pals@ietf.org> ; Kireeti Kompella <kireeti@juniper.net
<mailto:kireeti@juniper.net> >; Ron Bonica <rbonica@juniper.net
<mailto:rbonica@juniper.net> >; <rtg-ads@ietf.org <mailto:rtg-ads@ietf.org>
> <rtg-ads@ietf.org <mailto:rtg-ads@ietf.org> >
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

 

[External Email. Be cautious of content]

 

The DetNet CW is described in RFC8964 and is  

 

 

 
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0|                Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                       Figure 5: DetNet Control Word
 
In all defined control words
 
The 0000 is simply ECMP defeat and has no other purpose.
 
0001 means ACH 
 
An ACH is currently defined not to carry service/user data - it is a
control/OAM channel.
 
You cannot assume anything about a payload starting 0000.
 
In MPLS the bottom label (alone) defines how you process the payload. So you
know that you have a CW from the bottom label and by no other means.
 
In other words the the FEC of the bottom label and its associated parameters
are the way that signalling protocol knows what instructions to give the
forwarder, and the way that the forwarder knows what to do with the packet
is from the instructions associated with the BoS label. This is the
universal model for MPLS including for IP packets.
 
Stewart
 

 

On 19 Feb 2021, at 15:42, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net
<mailto:zzhang@juniper.net> > wrote:

 

Hi Stewart,

I still have to read more about DetNet, but I am not sure if there is a real
contention with PALS.

My understanding of 0000 nibble in PW control world is that it is only to
prevent a transit node from mistaking the payload as IP. Is it supposed to
indicate that any payload starting with 0000 is PW payload? I hope not.

Use of 0000 nibble in GDFH is also just to prevent transit nodes from
mistaking it as IP. It does indicate it is GDFH. It should be able to
co-exist with PW CW.

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 18, 2021 10:35 PM
To: Stewart Bryant <stewart.bryant@gmail.com
<mailto:stewart.bryant@gmail.com> >
Cc: int-area@ietf.org <mailto:int-area@ietf.org> ; mpls <mpls@ietf.org
<mailto:mpls@ietf.org> >; pals@ietf.org <mailto:pals@ietf.org> ; Kireeti
Kompella <kireeti@juniper.net <mailto:kireeti@juniper.net> >; Ron Bonica
<rbonica@juniper.net <mailto:rbonica@juniper.net> >; <rtg-ads@ietf.org
<mailto:rtg-ads@ietf.org> > <rtg-ads@ietf.org <mailto:rtg-ads@ietf.org> >
Subject: RE: draft-zzhang-intarea-generic-delivery-functions

Stewart, all,

I apologize for not responding to this in time. I some how accidentally
moved a few wg mailing list email folders to a place where I could not see
so I missed all the discussions.
Let me catch up all the emails and then reply.

Thanks.
Jeffrey

-----Original Message-----
From: Stewart Bryant <stewart.bryant@gmail.com
<mailto:stewart.bryant@gmail.com> >
Sent: Tuesday, January 12, 2021 9:59 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net <mailto:zzhang@juniper.net>
>
Cc: Stewart Bryant <stewart.bryant@gmail.com
<mailto:stewart.bryant@gmail.com> >; int-area@ietf.org
<mailto:int-area@ietf.org> ; mpls <mpls@ietf.org <mailto:mpls@ietf.org> >;
pals@ietf.org <mailto:pals@ietf.org> ; Kireeti Kompella <kireeti@juniper.net
<mailto:kireeti@juniper.net> >; Ron Bonica <rbonica@juniper.net
<mailto:rbonica@juniper.net> >; <rtg-ads@ietf.org <mailto:rtg-ads@ietf.org>
> <rtg-ads@ietf.org <mailto:rtg-ads@ietf.org> >
Subject: Re: draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]


Thank you Jeffery

Please see the note that I sent about iOAM who also want to sit after BoS .
and both of you want the same space that PALS and DetNet is already using.

We plan to have a joint session on this hosted by PALS at the next IETF, but
I think we also need to include the iOAM people.

This has scope to get very messy as we find new candidates for BoS metadata
so we really need to take a holistic position to ensure the future health
the MPLS protocol.

- Stewart



On 12 Jan 2021, at 14:27, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net
<mailto:zzhang@juniper.net> > wrote:

Hi,

I just posted
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-in
tarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kx
FtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-in
tarea-generic-delivery-functions/__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kx
FtiItOdNuXbu_RIMekK2pkpOj4Mmj7b9MseV-Y$>  .

The initial version was posted to the tsvwg
(https://urldefense.com/v3/__https://tools.ietf.org/html/draft-zzhang-tsvwg-
generic-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFti
ItOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$
<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zzhang-tsvwg-g
eneric-transport-functions-00__;!!NEt6yMaO-gk!QyBnufJO58LP6Diq96EdYEe2kxFtiI
tOdNuXbu_RIMekK2pkpOj4Mmj7b5lS_Jea$>  ). After discussions/feedback we are
re-homing it to intarea wg. This new version also contains quite some
changes based on the comments and feedback that we received (special thanks
to Stewart).

Comments and suggestions are appreciated.

Thanks.
Jeffrey

Juniper Business Use Only



Juniper Business Use Only

 

 

Juniper Business Use Only

 

 

Juniper Business Use Only

 

Juniper Business Use Only