From nobody Mon Jul 3 02:52:42 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3298F12EC18; Mon, 3 Jul 2017 02:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 cXwb5cp4T3t0; Mon, 3 Jul 2017 02:52:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9438F1289C3; Mon, 3 Jul 2017 02:52:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJQ32271; Mon, 03 Jul 2017 09:52:35 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Jul 2017 10:52:06 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 3 Jul 2017 17:52:01 +0800 From: Qin Wu To: "l3sm@ietf.org" , "l2sm@ietf.org" CC: "adrian@olddog.co.uk" , "Benoit Claise (bclaise)" Thread-Topic: Followup of RFC8049bis Thread-Index: AdLz4gQczWlV+rrbRBePS8Ez8xfWvQ== Date: Mon, 3 Jul 2017 09:52:00 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A9956B2nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.595A13E3.00F6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4f3feb204b41f273a8b540d91adafc40 Archived-At: Subject: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 09:52:40 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9A9956B2nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, All: The v-(02) of RFC8049bis has just been posted, https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ thanks Jan and David for valuable comments and input, the main changes incl= ude: 1.Specify what type of IPv6 address in the model for IPv6 connection? link-= local global 2.Specify provider address and a list of start-end addresses from provider = address 3.remove redundant parameters such as deny-any-except and permit-any-except= under cloud-access? 4. Add a few text to clarify what the site is in section 6.3 5. Add a few text to clarify why having customer-name. 6. Fixed two typos pointed by Jan recently. Talking with L3Sm design team, we believe how information is communicated b= y SP to the customer is beyond the scope of RFC8049 has already been clarified in section 6.6, 2nd paragraph, section 6= .6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.12.2.2,4th paragraph. Regarding whether AS number under BGP protocol is supposed to be the custom= er's AS number or the SP's AS number, we think AS number as part of BGP protocol related parameters are applied to provider to customer= boundary, therefore the answer is depending on how the management model is administered. As Jan pointed out, we still have some new mandatory fields introduced in v= -(02) haven't been reflected in the examples. But he is okay with the curre= nt shape. Please review these changes, let us know if there is any additional comment= s. Regards! Qin (on behalf of team) --_000_B8F9A780D330094D99AF023C5877DABA9A9956B2nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, All:

The v-(02) of RFC8049bis has ju= st been posted,

https://datatracker.ietf.org/doc= /draft-wu-l3sm-rfc8049bis/

thanks Jan and David for valuab= le comments and input, the main changes include:

1.Specify what type of IPv6 address in the model for IPv6 connec= tion? link-local global

2.Specify provider address and a list of start-end addresses fro= m provider address

3.remove redundant parameters such as deny-any-except and permit= -any-except under cloud-access?

4. Add a few text to clarify wh= at the site is in section 6.3

5. Add a few text to clarify wh= y having customer-name.

6. Fixed two typos pointed by J= an recently.

 

Talking with L3Sm design team, = we believe how information is communicated by SP to the customer is beyond = the scope of

RFC8049 has already been clarified in section 6.6, 2nd= paragraph, section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.= 12.2.2,4th paragraph.

 

Regarding whether AS number und= er BGP protocol is supposed to be the customer's AS number or the SP's AS n= umber, we think AS number as

part of BGP protocol related pa= rameters are applied to provider to customer boundary, therefore the answer= is depending on

how the management model is administered.

 

As Jan pointed out, we still have some new mandatory f= ields introduced in v-(02) haven’t been reflected in the examples. Bu= t he is okay with the current shape.

Please review these changes, let us know if there is a= ny additional comments.

 

Regards!

Qin (on behalf of team)

 

 

--_000_B8F9A780D330094D99AF023C5877DABA9A9956B2nkgeml513mbxchi_-- From nobody Wed Jul 5 04:46:59 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A6131CB1; Wed, 5 Jul 2017 04:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jM7Ype992sMa; Wed, 5 Jul 2017 04:46:54 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51E01201F2; Wed, 5 Jul 2017 04:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21030; q=dns/txt; s=iport; t=1499255214; x=1500464814; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=dTFq98eIp6497IQTho8vJKS9aCS9Hx3O+Kcf7Jt5yco=; b=CKjuK09NHW71/VyPZq2V31qsS8V9FbVRMZjoAyHZmeNQp98+u7f94AIk 9gwEZaOPKrLneuhfUbPyp6yBjOf7L1lPd4vHx6yYk6sTfL5t5PgoLNE5F RIFal5Qk3HMjzb0hTf64RlxkWox9oI6+k/LoDHoU0uf7q+rhIVinJLtzo M=; X-IronPort-AV: E=Sophos;i="5.40,311,1496102400"; d="scan'208,217";a="655883765" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2017 11:46:52 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v65BkpvW007462; Wed, 5 Jul 2017 11:46:51 GMT To: Qin Wu , "l3sm@ietf.org" , "l2sm@ietf.org" Cc: "Benoit Claise (bclaise)" , "adrian@olddog.co.uk" References: From: David Ball Message-ID: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> Date: Wed, 5 Jul 2017 12:46:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CFA03018E87AF0C12433CD5A" Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 11:46:58 -0000 This is a multi-part message in MIME format. --------------CFA03018E87AF0C12433CD5A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Qin. I thought it might be useful to summarize the discussion on each of my original questions so far. In general, I imagine that if I had a question, other readers might have the same question too, so even if we have answered the question on the thread, I think it is good to provide the clarification in the text as well. 1. You mention below that you think this is already described in section 6.6 and 6.12. However, the fact that the model only covers information requested by the customer to the SP is a key aspect of the model that is critical to the reader's understanding, so I think it needs to be explained much more clearly, and much earlier in the document i.e. in section 5. 2. As far as I saw, you only added one sentence about this - I think a bit more is needed! In fact I wonder if we are even all on the same page in the emails, since your answer didn't seem to quite align with what Kenichi and Stephane said. 3. I didn't see any text added to address this - and again, I'm not sure we're all on the same page yet. Kenichi agreed that there is no technical difference between using SubVPN and using multiple sites, although obviously this is related to question 2. At the very least, the ambiguity in the existing text should be fixed! 4. Addressed in the new draft 5. Conclusion is that using a single VPN service for multiple clouds is technically the same as using a separate VPN service for each cloud, but it might be easier operationally. This needs to be explained in the draft. 6. Addressed in the new draft 7. Can be addressed with an augment, so no change needed 8. You agreed to add some additional explanation about MTU, but I didn't see any changes in the draft? 9. Conclusion was that max routes per VPN might be useful but hard to implement, so no change needed. 10. Per-VPN QoS policy can be achieved in most cases using the target-sites option - need to add text to explain this 11. Can specify different performance objectives by using more classes, no change needed 12. I still don't understand what the SP is supposed to do in a multipoint case where end-to-end is true. Actually, even in a P2P case, there is a problem if the guaranteed end-to-end bandwidth is specified differently at each end. Should the SP take the higher or lower value? 13. Routing: 1. Agreed no change needed 2. Agreed no change needed 3. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer. Need to explain this in the text. 4. Addressed in the new draft 5. I did not understand your comment about the BGP AS number below - all the attributes in the model are applied at the customer to SP boundary, but it still needs to be clarified whether it is the customer's or SP's AS number. Actually given that the model is only covering what the customer requests, I guess it would always be the customer's AS number (since the customer wouldn't need to request the SP's AS number, that would be provided by the SP to the customer, which is outside the scope of the model). So I think the text should clarify that this is the customer's AS number. 6. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer. Need to explain this in the text. 7. Number of BGP sessions - SP decides and tells the customer, so this is outside the scope. Need to clarify in the text. 8. Model does not cover the case of eBGP multihop between loopbacks - need to mention this in the text. 9. Agreed no change needed 14. I didn't see an answer from anyone on why the BFD parameters can only be specified per access link. It seems useful to me to allow them to be specified per site too, like many other attributes. 15. Connection Addressing: 1. I saw you added the provider address and mask to the model for the DHCP and DHCP relay cases - but if the model is only covering information requested by the customer, then this doesn't seem right. Instead, the text should explain that they are supplied by the SP and thus are outside the scope of the model. 2. Addressed in the new draft - customer can request either a number of addresses or an explicit list of address ranges. 3. Agreed no change needed 4. I saw you added a leaf for this, but I'm not sure that's quite right. I'm not an IPv6 expert, but I thought LL addresses are always there; my question was not "LL addresses or global addresses?", it was "LL addresses only, or both LL and global addresses?". If it's LL only, then I don't think any of the other options apply - there is no need for static addresses, DHCP or SLAAC if the link only uses LL addresses. 16. Kenichi agreed there is an issue here, but I didn't see any fix in the new draft? 17. Not sure we reached a conclusion on this one... Thanks, David On 03/07/2017 10:52, Qin Wu wrote: > > Hi, All: > > The v-(02) of RFC8049bis has just been posted, > > https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ > > thanks Jan and David for valuable comments and input, the main changes > include: > > 1.Specify what type of IPv6 address in the model for IPv6 connection? > link-local global > > 2.Specify provider address and a list of start-end addresses from > provider address > > 3.remove redundant parameters such as deny-any-except and > permit-any-except under cloud-access? > > 4. Add a few text to clarify what the site is in section 6.3 > > 5. Add a few text to clarify why having customer-name. > > 6. Fixed two typos pointed by Jan recently. > > Talking with L3Sm design team, we believe how information is > communicated by SP to the customer is beyond the scope of > > RFC8049 has already been clarified in section 6.6, 2nd paragraph, > section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section > 6.12.2.2,4th paragraph. > > Regarding whether AS number under BGP protocol is supposed to be the > customer's AS number or the SP's AS number, we think AS number as > > part of BGP protocol related parameters are applied to provider to > customer boundary, therefore the answer is depending on > > how the management model is administered. > > As Jan pointed out, we still have some new mandatory fields introduced > in v-(02) haven’t been reflected in the examples. But he is okay with > the current shape. > > Please review these changes, let us know if there is any additional > comments. > > Regards! > > Qin (on behalf of team) > > > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm -- David Ball --------------CFA03018E87AF0C12433CD5A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Thanks Qin.

I thought it might be useful to summarize the discussion on each of my original questions so far.  In general, I imagine that if I had a question, other readers might have the same question too, so even if we have answered the question on the thread, I think it is good to provide the clarification in the text as well.

  1. You mention below that you think this is already described in section 6.6 and 6.12.  However, the fact that the model only covers information requested by the customer to the SP is a key aspect of the model that is critical to the reader's understanding, so I think it needs to be explained much more clearly, and much earlier in the document i.e. in section 5.
  2. As far as I saw, you only added one sentence about this - I think a bit more is needed!  In fact I wonder if we are even all on the same page in the emails, since your answer didn't seem to quite align with what Kenichi and Stephane said.
  3. I didn't see any text added to address this - and again, I'm not sure we're all on the same page yet.  Kenichi agreed that there is no technical difference between using SubVPN and using multiple sites, although obviously this is related to question 2.  At the very least, the ambiguity in the existing text should be fixed!
  4. Addressed in the new draft
  5. Conclusion is that using a single VPN service for multiple clouds is technically the same as using a separate VPN service for each cloud, but it might be easier operationally.  This needs to be explained in the draft.
  6. Addressed in the new draft
  7. Can be addressed with an augment, so no change needed
  8. You agreed to add some additional explanation about MTU, but I didn't see any changes in the draft?
  9. Conclusion was that max routes per VPN might be useful but hard to implement, so no change needed.
  10. Per-VPN QoS policy can be achieved in most cases using the target-sites option - need to add text to explain this
  11. Can specify different performance objectives by using more classes, no change needed
  12. I still don't understand what the SP is supposed to do in a multipoint case where end-to-end is true.  Actually, even in a P2P case, there is a problem if the guaranteed end-to-end bandwidth is specified differently at each end.  Should the SP take the higher or lower value?
  13. Routing:
    1. Agreed no change needed
    2. Agreed no change needed
    3. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer.  Need to explain this in the text.
    4. Addressed in the new draft
    5. I did not understand your comment about the BGP AS number below - all the attributes in the model are applied at the customer to SP boundary, but it still needs to be clarified whether it is the customer's or SP's AS number.  Actually given that the model is only covering what the customer requests, I guess it would always be the customer's AS number (since the customer wouldn't need to request the SP's AS number, that would be provided by the SP to the customer, which is outside the scope of the model).  So I think the text should clarify that this is the customer's AS number.
    6. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer.  Need to explain this in the text.
    7. Number of BGP sessions - SP decides and tells the customer, so this is outside the scope.  Need to clarify in the text.
    8. Model does not cover the case of eBGP multihop between loopbacks - need to mention this in the text.
    9. Agreed no change needed
  14. I didn't see an answer from anyone on why the BFD parameters can only be specified per access link.  It seems useful to me to allow them to be specified per site too, like many other attributes.
  15. Connection Addressing:
    1. I saw you added the provider address and mask to the model for the DHCP and DHCP relay cases - but if the model is only covering information requested by the customer, then this doesn't seem right.  Instead, the text should explain that they are supplied by the SP and thus are outside the scope of the model.
    2. Addressed in the new draft - customer can request either a number of addresses or an explicit list of address ranges.
    3. Agreed no change needed
    4. I saw you added a leaf for this, but I'm not sure that's quite right.  I'm not an IPv6 expert, but I thought LL addresses are always there; my question was not "LL addresses or global addresses?", it was "LL addresses only, or both LL and global addresses?".  If it's LL only, then I don't think any of the other options apply - there is no need for static addresses, DHCP or SLAAC if the link only uses LL addresses.
  16. Kenichi agreed there is an issue here, but I didn't see any fix in the new draft?
  17. Not sure we reached a conclusion on this one...


Thanks,


    David


On 03/07/2017 10:52, Qin Wu wrote:

Hi, All:

The v-(02) of RFC8049bis has just been posted,

https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/

thanks Jan and David for valuable comments and input, the main changes include:

1.Specify what type of IPv6 address in the model for IPv6 connection? link-local global

2.Specify provider address and a list of start-end addresses from provider address

3.remove redundant parameters such as deny-any-except and permit-any-except under cloud-access?

4. Add a few text to clarify what the site is in section 6.3

5. Add a few text to clarify why having customer-name.

6. Fixed two typos pointed by Jan recently.

 

Talking with L3Sm design team, we believe how information is communicated by SP to the customer is beyond the scope of

RFC8049 has already been clarified in section 6.6, 2nd paragraph, section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.12.2.2,4th paragraph.

 

Regarding whether AS number under BGP protocol is supposed to be the customer's AS number or the SP's AS number, we think AS number as

part of BGP protocol related parameters are applied to provider to customer boundary, therefore the answer is depending on

how the management model is administered.

 

As Jan pointed out, we still have some new mandatory fields introduced in v-(02) haven’t been reflected in the examples. But he is okay with the current shape.

Please review these changes, let us know if there is any additional comments.

 

Regards!

Qin (on behalf of team)

 

 



_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm


-- 
David Ball
<daviball@cisco.com>
--------------CFA03018E87AF0C12433CD5A-- From nobody Thu Jul 6 05:05:07 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E121316B9 for ; Thu, 6 Jul 2017 05:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3bImsxrPP4s3 for ; Thu, 6 Jul 2017 05:05:03 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E2813155F for ; Thu, 6 Jul 2017 05:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=380; q=dns/txt; s=iport; t=1499342703; x=1500552303; h=subject:from:to:references:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=rHnN/m20ITJN3tImY0PpM5bIQRElRrg5l3LlGMeYR4c=; b=P70vrNDhz7RjAKba0jJQWcfxq5w0lcki97r5oJClcHI1h6r3JjiOX8Ht pexHrOjfZYl94TDPunOG687zF20pm85iQqg1a1QECVmyGzbO1rbQUgkFq emdCJJezI61UfJGJCcmpwh9MvpMoD5L8mCyVCnJ9MmEHzPf9lqBEt1nZw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AAACJ15Z/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhUyOCXOQdpYDghGGHAKDYxgBAgEBAQEBAQFrKIUZAQU4UQsOCi5XBgE?= =?us-ascii?q?MBgIBAYors3SLRAEBAQEBAQEBAgEBAQEBAQEhgyeDTIIMgnmBPIkiAQSJTIhaj?= =?us-ascii?q?GmUBoF0AYkvhnqMZIhUHziBCjEhCBsVSYUfgXg/NohyAQEB?= X-IronPort-AV: E=Sophos;i="5.40,317,1496102400"; d="scan'208";a="654090054" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2017 12:05:01 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v66C50Ml031204; Thu, 6 Jul 2017 12:05:00 GMT From: David Ball To: Qin Wu , "l3sm@ietf.org" References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> Message-ID: <79d0d82a-f810-0ca5-7f43-003f7f6c47a8@cisco.com> Date: Thu, 6 Jul 2017 13:05:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [L3sm] [L2sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 12:05:04 -0000 Hi Qin, On 05/07/2017 12:46, David Ball wrote: > 6. Addressed in the new draft This one was about the duplication of authorized/denied sites under the cloud access - I looked more carefully and I think you may have deleted the wrong ones? The new draft now has a choice "list-flavor" that only has one case... David -- David Ball From nobody Mon Jul 10 06:47:23 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06750131784; Mon, 10 Jul 2017 06:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham 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 f4kjqKJbSNpm; Mon, 10 Jul 2017 06:47:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754B9127076; Mon, 10 Jul 2017 06:47:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKC19066; Mon, 10 Jul 2017 13:47:15 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Jul 2017 14:47:13 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 10 Jul 2017 21:47:06 +0800 From: Qin Wu To: David Ball , "l3sm@ietf.org" , "l2sm@ietf.org" CC: "Benoit Claise (bclaise)" , "adrian@olddog.co.uk" Thread-Topic: [L3sm] Followup of RFC8049bis Thread-Index: AdLz4gQczWlV+rrbRBePS8Ez8xfWvQBX1HKAAQwkggA= Date: Mon, 10 Jul 2017 13:47:05 +0000 Message-ID: References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> In-Reply-To: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A9A7FBDnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59638563.0233, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d3fcfc43ea9619cf635afd1f9d4aa175 Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 13:47:22 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9A9A7FBDnkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 t6K8/sjLOiBEYXZpZCBCYWxsIFttYWlsdG86ZGF2aWJhbGxAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6 IDIwMTfE6jfUwjXI1SAxOTo0Nw0KytW8/sjLOiBRaW4gV3U7IGwzc21AaWV0Zi5vcmc7IGwyc21A aWV0Zi5vcmcNCrOty806IEJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpOyBhZHJpYW5Ab2xkZG9nLmNv LnVrDQrW98ziOiBSZTogW0wzc21dIEZvbGxvd3VwIG9mIFJGQzgwNDliaXMNCg0KDQpUaGFua3Mg UWluLg0KDQpJIHRob3VnaHQgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIHN1bW1hcml6ZSB0aGUgZGlz Y3Vzc2lvbiBvbiBlYWNoIG9mIG15IG9yaWdpbmFsIHF1ZXN0aW9ucyBzbyBmYXIuICBJbiBnZW5l cmFsLCBJIGltYWdpbmUgdGhhdCBpZiBJIGhhZCBhIHF1ZXN0aW9uLCBvdGhlciByZWFkZXJzIG1p Z2h0IGhhdmUgdGhlIHNhbWUgcXVlc3Rpb24gdG9vLCBzbyBldmVuIGlmIHdlIGhhdmUgYW5zd2Vy ZWQgdGhlIHF1ZXN0aW9uIG9uIHRoZSB0aHJlYWQsIEkgdGhpbmsgaXQgaXMgZ29vZCB0byBwcm92 aWRlIHRoZSBjbGFyaWZpY2F0aW9uIGluIHRoZSB0ZXh0IGFzIHdlbGwuDQoNCiAgMS4gIFlvdSBt ZW50aW9uIGJlbG93IHRoYXQgeW91IHRoaW5rIHRoaXMgaXMgYWxyZWFkeSBkZXNjcmliZWQgaW4g c2VjdGlvbiA2LjYgYW5kIDYuMTIuICBIb3dldmVyLCB0aGUgZmFjdCB0aGF0IHRoZSBtb2RlbCBv bmx5IGNvdmVycyBpbmZvcm1hdGlvbiByZXF1ZXN0ZWQgYnkgdGhlIGN1c3RvbWVyIHRvIHRoZSBT UCBpcyBhIGtleSBhc3BlY3Qgb2YgdGhlIG1vZGVsIHRoYXQgaXMgY3JpdGljYWwgdG8gdGhlIHJl YWRlcidzIHVuZGVyc3RhbmRpbmcsIHNvIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgZXhwbGFpbmVk IG11Y2ggbW9yZSBjbGVhcmx5LCBhbmQgbXVjaCBlYXJsaWVyIGluIHRoZSBkb2N1bWVudCBpLmUu IGluIHNlY3Rpb24gNS4NCiAgICAgIFtRaW5dOiBZb3UgbmVlZCB0byByZWFkIGNhcmVmdWxseSwg aXQgY2xlYXJseSBleHBsYWluIHdoYXQga2luZCBvZiBpbmZvcm1hdGlvbiByZXNwb25kZWQgYnkg U1AgdG8gdGhlIEN1c3RvbWVyIGlzIG5vdCBpbiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4g Rm9yIG1vc3Qgb2Ygb3RoZXIgaW5mb3JtYXRpb24sIGl0IGRvZXNuoa90IHJlcXVpcmUgU1AgdG8g cmVzcG9uZCBiYWNrIHRvIEN1c3RvbWVyLg0KU2VlIHNlY3Rpb24gNi42ICwgM3JkIHBhcmFncmFw aDoNCqGwSWYgYSBjb25zdHJhaW50IGlzIHRvbyBzdHJpY3QgYW5kIGNhbm5vdCBiZSBmdWxmaWxs ZWQsIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSBNVVNUIE5PVCBwcm92aXNpb24gdGhlIHNpdGUgYW5k IFNIT1VMRCBwcm92aWRlIHJlbGV2YW50IGluZm9ybWF0aW9uIHRvIHRoZSB1c2VyLqGxDQpTZWUg c2VjdGlvbiA2LjYuMyAybmQgcGFyYWdyYXBoICwxc3QgYnVsbGV0Og0KobBJZiB0aGUgInN0cmlj dCIgbGVhZiBpcyBlcXVhbCB0byAiZmFsc2UiKGRlZmF1bHQpIGFuZCBpZiB0aGUgcmVxdWVzdGVk IG1lZGlhIHR5cGUgY2Fubm90IGJlIGZ1bGZpbGxlZCwgdGhlIG1hbmFnZW1lbnQgc3lzdGVtIGNh biBzZWxlY3QgYW5vdGhlciBtZWRpYSB0eXBlLiAgVGhlIHN1cHBvcnRlZCBtZWRpYSB0eXBlcyBT SE9VTEQgYmUgY29tbXVuaWNhdGVkIGJ5IHRoZSBTUCB0byB0aGUgY3VzdG9tZXIgdmlhIGEgbWVj aGFuaXNtIHRoYXQgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50LqGxDQpTZWUgc2Vj dGlvbiA2LjEyLjIuMiw0dGggcGFyYWdyYXBoOg0KobBzb21lIGNvbnN0cmFpbnRzIG1heSBub3Qg YmUgY29tcGxldGVseSBmdWxmaWxsZWQgYnkgdGhlIFNQOyBpbiB0aGlzIGNhc2UsIHRoZSBTUCBz aG91bGQgYWR2aXNlIHRoZSBjdXN0b21lciBhYm91dCB0aGUgbGltaXRhdGlvbnMuICBIb3cgdGhp cyBjb21tdW5pY2F0aW9uIGlzIGRvbmUgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50 LqGxDQoNCiAgMS4gIEFzIGZhciBhcyBJIHNhdywgeW91IG9ubHkgYWRkZWQgb25lIHNlbnRlbmNl IGFib3V0IHRoaXMgLSBJIHRoaW5rIGEgYml0IG1vcmUgaXMgbmVlZGVkISAgSW4gZmFjdCBJIHdv bmRlciBpZiB3ZSBhcmUgZXZlbiBhbGwgb24gdGhlIHNhbWUgcGFnZSBpbiB0aGUgZW1haWxzLCBz aW5jZSB5b3VyIGFuc3dlciBkaWRuJ3Qgc2VlbSB0byBxdWl0ZSBhbGlnbiB3aXRoIHdoYXQgS2Vu aWNoaSBhbmQgU3RlcGhhbmUgc2FpZC4NCltRaW5dOiBTaXRlIG5vdGlvbiBoYXMgYmVlbiB3ZWxs IGNsYXJpZmllZCBpbiB0aGUgZG9jdW1lbnQ6DQoNCqGwICAgQSBzaXRlIGhhcyBzZXZlcmFsIGNo YXJhY3RlcmlzdGljczoNCg0KICAgbyAgVW5pcXVlIGlkZW50aWZpZXIgKHNpdGUtaWQpOiB1bmlx dWVseSBpZGVudGlmaWVzIHRoZSBzaXRlIHdpdGhpbg0KICAgICAgdGhlIG92ZXJhbGwgbmV0d29y ayBpbmZyYXN0cnVjdHVyZS4gIFRoZSBpZGVudGlmaWVyIGlzIGEgc3RyaW5nDQogICAgICB0aGF0 IGFsbG93cyBhbnkgZW5jb2RpbmcgZm9yIHRoZSBsb2NhbCBhZG1pbmlzdHJhdGlvbiBvZiB0aGUg VlBODQogICAgICBzZXJ2aWNlLg0KDQogICBvICBMb2NhdGlvbnMgKGxvY2F0aW9ucyk6IHNpdGUg bG9jYXRpb24gaW5mb3JtYXRpb24gdGhhdCBhbGxvd3MgZWFzeQ0KICAgICAgcmV0cmlldmFsIG9m IGluZm9ybWF0aW9uIGZyb20gdGhlIG5lYXJlc3QgYXZhaWxhYmxlIHJlc291cmNlcy4gIEENCiAg ICAgIHNpdGUgbWF5IGJlIGNvbXBvc2VkIG9mIG11bHRpcGxlIGxvY2F0aW9ucy4NCg0KICAgbyAg RGV2aWNlcyAoZGV2aWNlcyk6IGFsbG93cyB0aGUgY3VzdG9tZXIgdG8gcmVxdWVzdCBvbmUgb3Ig bW9yZQ0KICAgICAgY3VzdG9tZXIgcHJlbWlzZXMgZXF1aXBtZW50IGVudGl0aWVzIGZyb20gdGhl IFNQIGZvciBhIHBhcnRpY3VsYXINCiAgICAgIHNpdGUuDQoNCiAgIG8gIE1hbmFnZW1lbnQgKG1h bmFnZW1lbnQpOiBkZWZpbmVzIHRoZSB0eXBlIG9mIG1hbmFnZW1lbnQgZm9yIHRoZQ0KICAgICAg c2l0ZSAtLSBmb3IgZXhhbXBsZSwgY28tbWFuYWdlZCwgY3VzdG9tZXItbWFuYWdlZCwgb3IgcHJv dmlkZXItDQogICAgICBtYW5hZ2VkLiAgU2VlIFNlY3Rpb24gNi4xMDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzLTAxI3NlY3Rpb24tNi4xMD4uDQoN CiAgIG8gIFNpdGUgbmV0d29yayBhY2Nlc3NlcyAoc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzKTogZGVm aW5lcyB0aGUgbGlzdCBvZg0KICAgICAgbmV0d29yayBhY2Nlc3NlcyBhc3NvY2lhdGVkIHdpdGgg dGhlIHNpdGVzLCBhbmQgdGhlaXIgcHJvcGVydGllcw0KICAgICAgLS0gZXNwZWNpYWxseSBiZWFy ZXIsIGNvbm5lY3Rpb24sIGFuZCBzZXJ2aWNlIHBhcmFtZXRlcnMuDQqhsQ0KSSBhZGQgb25lIHNl bnRlbmNlIHRvIGdldCBjb25zaXN0IHdpdGggdGhpcy4gVGhlIHByb3Bvc2VkIGNoYW5nZXMgaGF2 ZSBnb3QgYXBwcm92ZWQgYnkgU3RlcGFuZSBhbmQgS2VuaWNoaSBhbHJlYWR5IGJlZm9yZSBwb3N0 aW5nIHRvIHRoZSBsaXN0Lg0KDQogIDEuICBJIGRpZG4ndCBzZWUgYW55IHRleHQgYWRkZWQgdG8g YWRkcmVzcyB0aGlzIC0gYW5kIGFnYWluLCBJJ20gbm90IHN1cmUgd2UncmUgYWxsIG9uIHRoZSBz YW1lIHBhZ2UgeWV0LiAgS2VuaWNoaSBhZ3JlZWQgdGhhdCB0aGVyZSBpcyBubyB0ZWNobmljYWwg ZGlmZmVyZW5jZSBiZXR3ZWVuIHVzaW5nIFN1YlZQTiBhbmQgdXNpbmcgbXVsdGlwbGUgc2l0ZXMs IGFsdGhvdWdoIG9idmlvdXNseSB0aGlzIGlzIHJlbGF0ZWQgdG8gcXVlc3Rpb24gMi4gIEF0IHRo ZSB2ZXJ5IGxlYXN0LCB0aGUgYW1iaWd1aXR5IGluIHRoZSBleGlzdGluZyB0ZXh0IHNob3VsZCBi ZSBmaXhlZCENCltRaW5dOkkgdGhpbmsgdGhlIGtleSBkaWZmZXJlbmNlIGJldHdlZW4gc3ViVlBO IGFuZCBtdWx0aS1WUE4gaXMgd2hldGhlciB0aGV5IHNoYXJlIHRoZSBzYW1lIGJlYXJlci4gSXQg aXMgY2xhcmlmaWVkIGluIHRoZSBzZWN0aW9uIDYuNS4xLjMNCqGwDQpJdCBpcyBzaW1pbGFyIHRv IGhhdmluZyBzZXBhcmF0ZSBzaXRlcywgYnV0IGluIHRoaXMgY2FzZSB0aGUgY3VzdG9tZXINCndh bnRzIHRvIHNoYXJlIHNvbWUgcGh5c2ljYWwgY29tcG9uZW50cyB3aGlsZSBtYWludGFpbmluZyBz dHJvbmcgY29tbXVuaWNhdGlvbiBpc29sYXRpb24gYmV0d2VlbiB0aGUgYWZmaWxpYXRlcy4NCqGx DQpQaHlzaWNhbCBjb21wb25lbnRzIGFyZSByZWZlcnJlZCB0byB0aGUgYmVhcmVyLg0KSSB0aGlu ayB0aGlzIGlzIHN1ZmZpY2llbnQuIElmIHlvdSB0aGluayB3ZSBzaG91bGQgZnVydGhlciBsaW1p dCBzdWJWUE4gdG8gdGhlIHNhbWUgYmVhcmVyIGFuZCBzYW1lIENQRSwgcGxlYXNlIGxldCBtZSBr bm93Lg0KDQogIDEuICBBZGRyZXNzZWQgaW4gdGhlIG5ldyBkcmFmdA0KICAyLiAgQ29uY2x1c2lv biBpcyB0aGF0IHVzaW5nIGEgc2luZ2xlIFZQTiBzZXJ2aWNlIGZvciBtdWx0aXBsZSBjbG91ZHMg aXMgdGVjaG5pY2FsbHkgdGhlIHNhbWUgYXMgdXNpbmcgYSBzZXBhcmF0ZSBWUE4gc2VydmljZSBm b3IgZWFjaCBjbG91ZCwgYnV0IGl0IG1pZ2h0IGJlIGVhc2llciBvcGVyYXRpb25hbGx5LiAgVGhp cyBuZWVkcyB0byBiZSBleHBsYWluZWQgaW4gdGhlIGRyYWZ0Lg0KW1Fpbl06IEkgYmVsaWV2ZSB1 c2luZyBhIHNlcGFyYXRlIFZQTiBzZXJ2aWNlIGZvciBlYWNoIGNsb3VkIGlzIG5vdCBpbiB0aGUg c2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gVGhpcyBkcmFmdCBjbGVhciBleHBsYWluZWQgdG8gc3Vw cG9ydCBwdWJsaWMgY2xvdWQgYWNjZXNzLCBzdXBwb3J0IHByaXZhdGUgY2xvdWQgYWNjZXNzIHdp dGggYSBzaW5nbGUgVlBOIHNlcnZpY2UuDQoNCiAgMS4gIEFkZHJlc3NlZCBpbiB0aGUgbmV3IGRy YWZ0DQogIDIuICBDYW4gYmUgYWRkcmVzc2VkIHdpdGggYW4gYXVnbWVudCwgc28gbm8gY2hhbmdl IG5lZWRlZA0KDQpbUWluXTogQWdyZWUsIGRvIHlvdSB0aGluayBzZWN0aW9uIDYuMSChsEZlYXR1 cmVzIGFuZCBBdWdtZW50YXRpb26hsSBpcyBzdWZmaWNpZW50IHRvIGFkZHJlc3MgeW91ciBjb21t ZW50IHdpdGggYW55IHRleHQgY2hhbmdlLg0KDQogIDEuICBZb3UgYWdyZWVkIHRvIGFkZCBzb21l IGFkZGl0aW9uYWwgZXhwbGFuYXRpb24gYWJvdXQgTVRVLCBidXQgSSBkaWRuJ3Qgc2VlIGFueSBj aGFuZ2VzIGluIHRoZSBkcmFmdD8NCltRaW5dOkFkZHJlc3NlZCBpbiB0aGUgcHJldmlvdXMgdmVy c2lvbiB3aGljaCBhZGRyZXNzIEphbqGvcyBjb21tZW50cywgU2VlDQqhsA0KICAgICBsZWFmIHN2 Yy1tdHUgew0KICAgICAgIHR5cGUgdWludDE2Ow0KICAgICAgIHVuaXRzIGJ5dGVzOw0KICAgICAg IG1hbmRhdG9yeSB0cnVlOw0KICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICJNVFUgYXQgc2Vy dmljZSBsZXZlbC4gSWYgdGhlIHNlcnZpY2UgaXMgSVAsDQogICAgICAgICBpdCByZWZlcnMgdG8g dGhlIElQIE1UVS4gSWYgQ3NDIGlzIGVuYWJsZWQsDQogICAgICAgICB0aGUgcmVxdWVzdGVkICdz dmMtbXR1JyBsZWFmIHdpbGwgcmVmZXIgdG8gdGhlDQogICAgICAgICBNUExTIE1UVSBhbmQgbm90 IHRvIHRoZSBJUCBNVFUuICI7DQqhsQ0KDQogIDEuICBDb25jbHVzaW9uIHdhcyB0aGF0IG1heCBy b3V0ZXMgcGVyIFZQTiBtaWdodCBiZSB1c2VmdWwgYnV0IGhhcmQgdG8gaW1wbGVtZW50LCBzbyBu byBjaGFuZ2UgbmVlZGVkLg0KICAyLiAgUGVyLVZQTiBRb1MgcG9saWN5IGNhbiBiZSBhY2hpZXZl ZCBpbiBtb3N0IGNhc2VzIHVzaW5nIHRoZSB0YXJnZXQtc2l0ZXMgb3B0aW9uIC0gbmVlZCB0byBh ZGQgdGV4dCB0byBleHBsYWluIHRoaXMNCltRaW5dOiBPa2F5Lg0KDQogIDEuICBDYW4gc3BlY2lm eSBkaWZmZXJlbnQgcGVyZm9ybWFuY2Ugb2JqZWN0aXZlcyBieSB1c2luZyBtb3JlIGNsYXNzZXMs IG5vIGNoYW5nZSBuZWVkZWQNCiAgMi4gIEkgc3RpbGwgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRo ZSBTUCBpcyBzdXBwb3NlZCB0byBkbyBpbiBhIG11bHRpcG9pbnQgY2FzZSB3aGVyZSBlbmQtdG8t ZW5kIGlzIHRydWUuICBBY3R1YWxseSwgZXZlbiBpbiBhIFAyUCBjYXNlLCB0aGVyZSBpcyBhIHBy b2JsZW0gaWYgdGhlIGd1YXJhbnRlZWQgZW5kLXRvLWVuZCBiYW5kd2lkdGggaXMgc3BlY2lmaWVk IGRpZmZlcmVudGx5IGF0IGVhY2ggZW5kLiAgU2hvdWxkIHRoZSBTUCB0YWtlIHRoZSBoaWdoZXIg b3IgbG93ZXIgdmFsdWU/DQoNCltRaW5dOiBJIHRoaW5rIHRoaXMgZGVwZW5kcyBvbiB0aGUgU1An cyBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VydmljZS4NCg0KICAxLiAgUm91dGluZzoNCiAgICAg KiAgIEFncmVlZCBubyBjaGFuZ2UgbmVlZGVkDQogICAgICogICBBZ3JlZWQgbm8gY2hhbmdlIG5l ZWRlZA0KICAgICAqICAgQ29uY2x1ZGVkIHRoYXQgb3RoZXIgcGFyYW1ldGVycyAodGltZXJzIGV0 YykgYXJlIHNldCBieSB0aGUgU1AgYW5kIGNvbW11bmljYXRlZCBvdXRzaWRlIG9mIHRoZSBtb2Rl bCwgbm90IHJlcXVlc3RlZCBieSB0aGUgY3VzdG9tZXIuICBOZWVkIHRvIGV4cGxhaW4gdGhpcyBp biB0aGUgdGV4dC4NCiAgICAgICAgICAgICAgICAgICAgW1Fpbl06IE9rYXkuDQoNCiAgICAgKiAg IEFkZHJlc3NlZCBpbiB0aGUgbmV3IGRyYWZ0DQogICAgICogICBJIGRpZCBub3QgdW5kZXJzdGFu ZCB5b3VyIGNvbW1lbnQgYWJvdXQgdGhlIEJHUCBBUyBudW1iZXIgYmVsb3cgLSBhbGwgdGhlIGF0 dHJpYnV0ZXMgaW4gdGhlIG1vZGVsIGFyZSBhcHBsaWVkIGF0IHRoZSBjdXN0b21lciB0byBTUCBi b3VuZGFyeSwgYnV0IGl0IHN0aWxsIG5lZWRzIHRvIGJlIGNsYXJpZmllZCB3aGV0aGVyIGl0IGlz IHRoZSBjdXN0b21lcidzIG9yIFNQJ3MgQVMgbnVtYmVyLiAgQWN0dWFsbHkgZ2l2ZW4gdGhhdCB0 aGUgbW9kZWwgaXMgb25seSBjb3ZlcmluZyB3aGF0IHRoZSBjdXN0b21lciByZXF1ZXN0cywgSSBn dWVzcyBpdCB3b3VsZCBhbHdheXMgYmUgdGhlIGN1c3RvbWVyJ3MgQVMgbnVtYmVyIChzaW5jZSB0 aGUgY3VzdG9tZXIgd291bGRuJ3QgbmVlZCB0byByZXF1ZXN0IHRoZSBTUCdzIEFTIG51bWJlciwg dGhhdCB3b3VsZCBiZSBwcm92aWRlZCBieSB0aGUgU1AgdG8gdGhlIGN1c3RvbWVyLCB3aGljaCBp cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgbW9kZWwpLiAgU28gSSB0aGluayB0aGUgdGV4dCBz aG91bGQgY2xhcmlmeSB0aGF0IHRoaXMgaXMgdGhlIGN1c3RvbWVyJ3MgQVMgbnVtYmVyLg0KICAg ICAgICAgICAgICAgIFtRaW5dIE5vdCBzdXJlIHdlIHNob3VsZCBkaXN0aW5jdCB0aGUgcGFyYW1l dGVyIHVzZWQgYnkgY3VzdG9tZXIgdG8gdGFsayB0byBwcm92aWRlciBmcm9tIHRoZSBwYXJhbWV0 ZXIgdXNlZCBieSBwcm92aWRlciB0byB0YWxrIHRvIGN1c3RvbWVyLiBJbiBUaGVvcnksIGJvdGgg Y3VzdG9tZXIgYW5kIHByb3ZpZGVyIGNhbiB1c2UgdGhpcyBtb2RlbCAgICBwYXJhbWV0ZXIgdG8g dGFsayB0byBlYWNoIG90aGVyLiBJIHdvdWxkIGxpa2UgdG8gaGVhciBvdGhlcqGvcyBvcGluaW9u Lg0KDQogICAgICogICBDb25jbHVkZWQgdGhhdCBvdGhlciBwYXJhbWV0ZXJzICh0aW1lcnMgZXRj KSBhcmUgc2V0IGJ5IHRoZSBTUCBhbmQgY29tbXVuaWNhdGVkIG91dHNpZGUgb2YgdGhlIG1vZGVs LCBub3QgcmVxdWVzdGVkIGJ5IHRoZSBjdXN0b21lci4gIE5lZWQgdG8gZXhwbGFpbiB0aGlzIGlu IHRoZSB0ZXh0Lg0KICAgICAgICAgICAgICAgICAgW1Fpbl06IE9rYXkuDQoNCiAgICAgKiAgIE51 bWJlciBvZiBCR1Agc2Vzc2lvbnMgLSBTUCBkZWNpZGVzIGFuZCB0ZWxscyB0aGUgY3VzdG9tZXIs IHNvIHRoaXMgaXMgb3V0c2lkZSB0aGUgc2NvcGUuICBOZWVkIHRvIGNsYXJpZnkgaW4gdGhlIHRl eHQuDQogICAgICAgICAgICAgIFtRaW5dOiBXaWxsIGNoZWNrIHRoaXMuDQoNCiAgICAgKiAgIE1v ZGVsIGRvZXMgbm90IGNvdmVyIHRoZSBjYXNlIG9mIGVCR1AgbXVsdGlob3AgYmV0d2VlbiBsb29w YmFja3MgLSBuZWVkIHRvIG1lbnRpb24gdGhpcyBpbiB0aGUgdGV4dC4NCiAgICAgICAgICBbUWlu XTogSSBhbSBub3Qgc3VyZSB3ZSBzaG91bGQgZW51bWVyYXRlIGFsbCB0aGUgY2FzZXMgdGhlIG1v ZGVsIGRvZXNuoa90IHN1cHBvcnQuIEl0IGlzIG5vLWVuZGluZy4gVGhpcyBtb2RlbCBpcyBqdXN0 IGEgYmFzZSBtb2RlbC4NCg0KICAgICAqICAgQWdyZWVkIG5vIGNoYW5nZSBuZWVkZWQNCiAgMS4g IEkgZGlkbid0IHNlZSBhbiBhbnN3ZXIgZnJvbSBhbnlvbmUgb24gd2h5IHRoZSBCRkQgcGFyYW1l dGVycyBjYW4gb25seSBiZSBzcGVjaWZpZWQgcGVyIGFjY2VzcyBsaW5rLiAgSXQgc2VlbXMgdXNl ZnVsIHRvIG1lIHRvIGFsbG93IHRoZW0gdG8gYmUgc3BlY2lmaWVkIHBlciBzaXRlIHRvbywgbGlr ZSBtYW55IG90aGVyIGF0dHJpYnV0ZXMuDQpbUWluXTogUGxlYXNlIHByb3ZpZGUgeW91ciB1c2Ug Y2FzZS4gTm90IHN1cmUgd2Ugc2hvdWxkIGFkZCB0aGlzLiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYg dGhlcmUgaXMgYSByZWFsIHVzZSBjYXNlLCBpdCBjYW4gYmUgYWRkZWQgdGhyb3VnaCBhdWdtZW50 YXRpb24uDQoNCiAgMS4gIENvbm5lY3Rpb24gQWRkcmVzc2luZzoNCiAgICAgKiAgIEkgc2F3IHlv dSBhZGRlZCB0aGUgcHJvdmlkZXIgYWRkcmVzcyBhbmQgbWFzayB0byB0aGUgbW9kZWwgZm9yIHRo ZSBESENQIGFuZCBESENQIHJlbGF5IGNhc2VzIC0gYnV0IGlmIHRoZSBtb2RlbCBpcyBvbmx5IGNv dmVyaW5nIGluZm9ybWF0aW9uIHJlcXVlc3RlZCBieSB0aGUgY3VzdG9tZXIsIHRoZW4gdGhpcyBk b2Vzbid0IHNlZW0gcmlnaHQuICBJbnN0ZWFkLCB0aGUgdGV4dCBzaG91bGQgZXhwbGFpbiB0aGF0 IHRoZXkgYXJlIHN1cHBsaWVkIGJ5IHRoZSBTUCBhbmQgdGh1cyBhcmUgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhlIG1vZGVsLg0KICAgICAgICAgICAgIFtRaW5dOiBZb3Ugc2V0IGEgcGl0ZmFsbCBm b3IgdXMgdG8ganVtcCw6KSwgYnV0IEkgaGF2ZSBjbGFyaWZpZWQgdGhpcyB0byB5b3UgYXQgdGhl IGJlZ2lubmluZy4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgd2hhdCBMM1NNIERlc2lnbiBUZWFtIHRo aW5rIGFib3V0IHRoaXM/DQoNCiAgICAgKiAgIEFkZHJlc3NlZCBpbiB0aGUgbmV3IGRyYWZ0IC0g Y3VzdG9tZXIgY2FuIHJlcXVlc3QgZWl0aGVyIGEgbnVtYmVyIG9mIGFkZHJlc3NlcyBvciBhbiBl eHBsaWNpdCBsaXN0IG9mIGFkZHJlc3MgcmFuZ2VzLg0KICAgICAqICAgQWdyZWVkIG5vIGNoYW5n ZSBuZWVkZWQNCiAgICAgKiAgIEkgc2F3IHlvdSBhZGRlZCBhIGxlYWYgZm9yIHRoaXMsIGJ1dCBJ J20gbm90IHN1cmUgdGhhdCdzIHF1aXRlIHJpZ2h0LiAgSSdtIG5vdCBhbiBJUHY2IGV4cGVydCwg YnV0IEkgdGhvdWdodCBMTCBhZGRyZXNzZXMgYXJlIGFsd2F5cyB0aGVyZTsgbXkgcXVlc3Rpb24g d2FzIG5vdCAiTEwgYWRkcmVzc2VzIG9yIGdsb2JhbCBhZGRyZXNzZXM/IiwgaXQgd2FzICJMTCBh ZGRyZXNzZXMgb25seSwgb3IgYm90aCBMTCBhbmQgZ2xvYmFsIGFkZHJlc3Nlcz8iLiAgSWYgaXQn cyBMTCBvbmx5LCB0aGVuIEkgZG9uJ3QgdGhpbmsgYW55IG9mIHRoZSBvdGhlciBvcHRpb25zIGFw cGx5IC0gdGhlcmUgaXMgbm8gbmVlZCBmb3Igc3RhdGljIGFkZHJlc3NlcywgREhDUCBvciBTTEFB QyBpZiB0aGUgbGluayBvbmx5IHVzZXMgTEwgYWRkcmVzc2VzLg0KICAgICAgIFtRaW5dOm5vdCBz dXJlIG9uZSBhZGRyZXNzIGNhbiBiZSBib3RoIExMIGFuZCBnbG9iYWwgYWRkcmVzcyBhdCB0aGUg c2FtZSB0aW1lLCBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoaXMgcGFyYW1ldGVyIGlmIHRo aXMgaW50cm9kdWNlIGNvbmZ1c2lvbi4NCg0KICAxLiAgS2VuaWNoaSBhZ3JlZWQgdGhlcmUgaXMg YW4gaXNzdWUgaGVyZSwgYnV0IEkgZGlkbid0IHNlZSBhbnkgZml4IGluIHRoZSBuZXcgZHJhZnQ/ DQogICAgW1Fpbl06IEl0IGlzIGxlZnQgb3ZlciBhbmQgd2lsbCBmaXggdGhpcy4NCg0KICAxLiAg Tm90IHN1cmUgd2UgcmVhY2hlZCBhIGNvbmNsdXNpb24gb24gdGhpcyBvbmUuLi4NCg0KICBbUWlu XTogTWV0cmljIGRlZmluZWQgaW4gdGhpcyBtb2RlbCBpcyB1c2VkIGZvciByb3V0aW5nIHN0YXRl IGNhbGN1bGF0aW9uIGFuZCBwYXRoIHNlbGVjdGlvbiB3aGlsZSBhY2Nlc3MgcHJpb3JpdHkgZGVm aW5lcyBkZWZpbmVzIGEgcHJlZmVyZW5jZSBmb3IgYSBwYXJ0aWN1bGFyIGFjY2VzcyBhbmQgZGVj aWRlIHByaW1hcnkvYmFja3VwIG9yIGxvYWRiYWxhbmNpbmcgcmVsYXRpb25zaGlwIGJldHdlZW4g bmV0d29yayBhY2Nlc3NlcywgdGhleSBzZXJ2ZSBkaWZmZXJlbmNlIHB1cnBvc2UsIGRvbqGvdCBt aXggdGhlbS4NCg0KVGhhbmtzLA0KDQoNCg0KICAgIERhdmlkDQoNCk9uIDAzLzA3LzIwMTcgMTA6 NTIsIFFpbiBXdSB3cm90ZToNCkhpLCBBbGw6DQpUaGUgdi0oMDIpIG9mIFJGQzgwNDliaXMgaGFz IGp1c3QgYmVlbiBwb3N0ZWQsDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXd1LWwzc20tcmZjODA0OWJpcy8NCnRoYW5rcyBKYW4gYW5kIERhdmlkIGZvciB2YWx1YWJs ZSBjb21tZW50cyBhbmQgaW5wdXQsIHRoZSBtYWluIGNoYW5nZXMgaW5jbHVkZToNCjEuU3BlY2lm eSB3aGF0IHR5cGUgb2YgSVB2NiBhZGRyZXNzIGluIHRoZSBtb2RlbCBmb3IgSVB2NiBjb25uZWN0 aW9uPyBsaW5rLWxvY2FsIGdsb2JhbA0KMi5TcGVjaWZ5IHByb3ZpZGVyIGFkZHJlc3MgYW5kIGEg bGlzdCBvZiBzdGFydC1lbmQgYWRkcmVzc2VzIGZyb20gcHJvdmlkZXIgYWRkcmVzcw0KMy5yZW1v dmUgcmVkdW5kYW50IHBhcmFtZXRlcnMgc3VjaCBhcyBkZW55LWFueS1leGNlcHQgYW5kIHBlcm1p dC1hbnktZXhjZXB0IHVuZGVyIGNsb3VkLWFjY2Vzcz8NCjQuIEFkZCBhIGZldyB0ZXh0IHRvIGNs YXJpZnkgd2hhdCB0aGUgc2l0ZSBpcyBpbiBzZWN0aW9uIDYuMw0KNS4gQWRkIGEgZmV3IHRleHQg dG8gY2xhcmlmeSB3aHkgaGF2aW5nIGN1c3RvbWVyLW5hbWUuDQo2LiBGaXhlZCB0d28gdHlwb3Mg cG9pbnRlZCBieSBKYW4gcmVjZW50bHkuDQoNClRhbGtpbmcgd2l0aCBMM1NtIGRlc2lnbiB0ZWFt LCB3ZSBiZWxpZXZlIGhvdyBpbmZvcm1hdGlvbiBpcyBjb21tdW5pY2F0ZWQgYnkgU1AgdG8gdGhl IGN1c3RvbWVyIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YNClJGQzgwNDkgaGFzIGFscmVhZHkgYmVl biBjbGFyaWZpZWQgaW4gc2VjdGlvbiA2LjYsIDJuZCBwYXJhZ3JhcGgsIHNlY3Rpb24gNi42LjMs Mm5kIHBhcmFncmFwaCwgMXN0IGJ1bGxldCwgM3JkIGJ1bGxldCwgc2VjdGlvbiA2LjEyLjIuMiw0 dGggcGFyYWdyYXBoLg0KDQpSZWdhcmRpbmcgd2hldGhlciBBUyBudW1iZXIgdW5kZXIgQkdQIHBy b3RvY29sIGlzIHN1cHBvc2VkIHRvIGJlIHRoZSBjdXN0b21lcidzIEFTIG51bWJlciBvciB0aGUg U1AncyBBUyBudW1iZXIsIHdlIHRoaW5rIEFTIG51bWJlciBhcw0KcGFydCBvZiBCR1AgcHJvdG9j b2wgcmVsYXRlZCBwYXJhbWV0ZXJzIGFyZSBhcHBsaWVkIHRvIHByb3ZpZGVyIHRvIGN1c3RvbWVy IGJvdW5kYXJ5LCB0aGVyZWZvcmUgdGhlIGFuc3dlciBpcyBkZXBlbmRpbmcgb24NCmhvdyB0aGUg bWFuYWdlbWVudCBtb2RlbCBpcyBhZG1pbmlzdGVyZWQuDQoNCkFzIEphbiBwb2ludGVkIG91dCwg d2Ugc3RpbGwgaGF2ZSBzb21lIG5ldyBtYW5kYXRvcnkgZmllbGRzIGludHJvZHVjZWQgaW4gdi0o MDIpIGhhdmVuoa90IGJlZW4gcmVmbGVjdGVkIGluIHRoZSBleGFtcGxlcy4gQnV0IGhlIGlzIG9r YXkgd2l0aCB0aGUgY3VycmVudCBzaGFwZS4NClBsZWFzZSByZXZpZXcgdGhlc2UgY2hhbmdlcywg bGV0IHVzIGtub3cgaWYgdGhlcmUgaXMgYW55IGFkZGl0aW9uYWwgY29tbWVudHMuDQoNClJlZ2Fy ZHMhDQpRaW4gKG9uIGJlaGFsZiBvZiB0ZWFtKQ0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTDNzbSBtYWlsaW5nIGxpc3QNCg0K TDNzbUBpZXRmLm9yZzxtYWlsdG86TDNzbUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoNCg0KDQotLQ0KDQpEYXZpZCBCYWxsDQoNCjxkYXZp YmFsbEBjaXNjby5jb20+PG1haWx0bzpkYXZpYmFsbEBjaXNjby5jb20+DQo= --_000_B8F9A780D330094D99AF023C5877DABA9A9A7FBDnkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

=B7=A2= =BC=FE=C8=CB: David B= all [mailto:daviball@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo= r:windowtext"> 2017=C4=EA7=D4=C25=C8=D5 19:47
=CA=D5=BC=FE=C8=CB: Qin Wu; l3sm@ietf.org; l2sm@ietf.org
=B3=AD=CB=CD: Benoit Claise (bclaise); adrian@olddog.co.uk
=D6=F7=CC=E2: Re: [L3sm] Followup of RFC8049bis

 

Thanks Qin.

I thought it might be useful to summarize the discu= ssion on each of my original questions so far.  In general, I imagine = that if I had a question, other readers might have the same question too, s= o even if we have answered the question on the thread, I think it is good to provide the clarification in the text= as well.

  1. You mention below that you think this is already descr= ibed in section 6.6 and 6.12.  However, the fact that the model only c= overs information requested by the customer to the SP is a key aspect of th= e model that is critical to the reader's understanding, so I think it needs to be explained much more clearly, and = much earlier in the document i.e. in section 5.

   &nb= sp;  [Qin]: You need to read carefully, it clearly explain what kind o= f information responded by SP to the Customer is not in the scope of this document. For most of other information, it doesn=A1=AFt require S= P to respond back to Customer.

See section 6.6 , 3rd paragraph:

=A1=B0If a constraint= is too strict and cannot be fulfilled, the management system MUST NOT prov= ision the site and SHOULD provide relevant information to the user.=A1=B1

See section 6.6.3 2nd paragraph ,1st bullet:

=A1=B0If the "st= rict" leaf is equal to "false"(default) and if the requested= media type cannot be fulfilled, the management system can select another media type.  The supported media types SHOULD be communicated= by the SP to the customer via a mechanism that is out of scope for this do= cument.=A1=B1

See section 6.12.2.2,= 4th paragraph:

=A1=B0some constraint= s may not be completely fulfilled by the SP; in this case, the SP should ad= vise the customer about the limitations.  How this communication is done is out of scope for this document.=A1=B1

  1. As far as I saw, you only added one sentence about thi= s - I think a bit more is needed!  In fact I wonder if we are even all= on the same page in the emails, since your answer didn't seem to quite ali= gn with what Kenichi and Stephane said.

[Qin]: Site notion ha= s been well clarified in the document:

=A1=B0   A site has several characteristics:

 

   o  Unique identifier (site-id): uniquely ident= ifies the site within

      the overall network infrastructur= e.  The identifier is a string

      that allows any encoding for the = local administration of the VPN

      service.

 

   o  Locations (locations): site location inform= ation that allows easy

      retrieval of information from the= nearest available resources.  A

      site may be composed of multiple = locations.

 

   o  Devices (devices): allows the customer to r= equest one or more

      customer premises equipment entit= ies from the SP for a particular

      site.

 

   o  Management (management): defines the type o= f management for the

      site -- for example, co-managed, = customer-managed, or provider-

      managed.  See Section 6.10.

 

   o  Site network accesses (site-network-accesse= s): defines the list of

      network accesses associated with = the sites, and their properties

      -- especially bearer, connection,= and service parameters.

=A1=B1

I add one sentence to= get consist with this. The proposed changes have got approved by Stepane a= nd Kenichi already before posting to the list.

  1. I didn't see any text added to address this - and agai= n, I'm not sure we're all on the same page yet.  Kenichi agreed that t= here is no technical difference between using SubVPN and using multiple sit= es, although obviously this is related to question 2.  At the very least, the ambiguity in the existing text= should be fixed!

[Qin]:I think the key= difference between subVPN and multi-VPN is whether they share the same bea= rer. It is clarified in the section 6.5.1.3

=A1=B0

It is similar to having separate sites, but in this case the cus= tomer

wants to share some physical components while maintaining strong= communication isolation between the affiliates.

=A1=B1

Physical components a= re referred to the bearer.

I think this is suffi= cient. If you think we should further limit subVPN to the same bearer and s= ame CPE, please let me know.

  1. Addressed in the new draft
  2. Conclusion is that using a single VPN service for mult= iple clouds is technically the same as using a separate VPN service for eac= h cloud, but it might be easier operationally.  This needs to be expla= ined in the draft.

[Qin]: I believe usin= g a separate VPN service for each cloud is not in the scope of this documen= t. This draft clear explained to support public cloud access, support private cloud access with a single VPN servic= e.

  1. Addressed in the new draft
  2. Can be addressed with an augment, so no change needed<= o:p>
[Qin]: Agr=
ee, do you think section 6.1 =A1=B0Features and Augmentation=A1=B1 is suffi=
cient to address your comment with any text change.<=
/o:p>
  1. You agreed to add some additional explanation about MT= U, but I didn't see any changes in the draft?

[Qin]:Addressed in th= e previous version which address Jan=A1=AFs comments, See

=A1=B0

   &nb= sp; leaf svc-mtu { 

   &nb= sp;   type uint16; 

   &nb= sp;   units bytes; 

   &nb= sp;   mandatory true; 

   &nb= sp;   description 

   &nb= sp;    "MTU at service level. If the service is IP= , 

   &nb= sp;     it refers to the IP MTU. If CsC is enabled= , 

   &nb= sp;     the requested 'svc-mtu' leaf will refer to= the 

   &nb= sp;     MPLS MTU and not to the IP MTU. ";

=A1=B1

  1. Conclusion was that max routes per VPN might be useful= but hard to implement, so no change needed.
  2. Per-VPN QoS policy can be achieved in most cases using= the target-sites option - need to add text to explain this

[Qin]: Okay.

  1. Can specify different performance objectives by using = more classes, no change needed
  2. I still don't understand what the SP is supposed to do= in a multipoint case where end-to-end is true.  Actually, even in a P= 2P case, there is a problem if the guaranteed end-to-end bandwidth is speci= fied differently at each end.  Should the SP take the higher or lower value?
[Qin]: I t=
hink this depends on the SP's implementation of the service.
  1. Routing:
    1. Agreed no change needed
    2. Agreed no change needed
    3. Concluded that other parameters (timers etc) are set b= y the SP and communicated outside of the model, not requested by the custom= er.  Need to explain this in the text.

   &nb= sp;            =     [Qin]: Okay.

    1. Addressed in the new draft
    2. I did not understand your comment about the BGP AS num= ber below - all the attributes in the model are applied at the customer to = SP boundary, but it still needs to be clarified whether it is the customer'= s or SP's AS number.  Actually given that the model is only covering what the customer requests, I guess it wou= ld always be the customer's AS number (since the customer wouldn't need to = request the SP's AS number, that would be provided by the SP to the custome= r, which is outside the scope of the model).  So I think the text should clarify that this is the cust= omer's AS number.

    &n= bsp;           [Qin]= Not sure we should distinct the parameter used by customer to talk to prov= ider from the parameter used by provider to talk to customer. In Theory, both customer and provider can use this mo= del    parameter to talk to each other. I would like to hear= other=A1=AFs opinion.

    1. Concluded that other parameters (timers etc) are set b= y the SP and communicated outside of the model, not requested by the custom= er.  Need to explain this in the text.

   &nb= sp;             = ; [Qin]: Okay.

    1. Number of BGP sessions - SP decides and tells the cust= omer, so this is outside the scope.  Need to clarify in the text.=

   &nb= sp;          [Qin]: Will check= this.

    1. Model does not cover the case of eBGP multihop between= loopbacks - need to mention this in the text.

   &nb= sp;      [Qin]: I am not sure we should enumerate = all the cases the model doesn=A1=AFt support. It is no-ending. This model i= s just a base model.

    1. Agreed no change needed
  1. I didn't see an answer from anyone on why the BFD para= meters can only be specified per access link.  It seems useful to me t= o allow them to be specified per site too, like many other attributes.=

[Qin]: Please provide your use= case. Not sure we should add this. On the other hand, if there is a real u= se case, it can be added through augmentation.

  1. Connection Addressing:
    1. I saw you added the provider address and mask to the m= odel for the DHCP and DHCP relay cases - but if the model is only covering = information requested by the customer, then this doesn't seem right.  = Instead, the text should explain that they are supplied by the SP and thus are outside the scope of the model.

   &nb= sp;         [Qin]: You set a pitfal= l for us to jump,J, but I have clarified this to you at the beginning. I would like to hear wh= at L3SM Design Team think about this?

    1. Addressed in the new draft - customer can request eith= er a number of addresses or an explicit list of address ranges.<= /span>
    2. Agreed no change needed
    3. I saw you added a leaf for this, but I'm not sure that= 's quite right.  I'm not an IPv6 expert, but I thought LL addresses ar= e always there; my question was not "LL addresses or global addresses?= ", it was "LL addresses only, or both LL and global addresses?".  If it's LL only, then I don't think any of = the other options apply - there is no need for static addresses, DHCP or SL= AAC if the link only uses LL addresses.

   &nb= sp;   [Qin]:not sure one address can be both LL and global addres= s at the same time, I would suggest to remove this parameter if this introd= uce confusion.

  1. Kenichi agreed there is an issue here, but I didn't se= e any fix in the new draft?

    [Q= in]: It is left over and will fix this.

  1. Not sure we reached a conclusion on this one...
  [Qin]: Metric defined in this model is used for routing state=
 calculation and path selection while access priority defines defines a pre=
ference for a particular access and decide primary/backup or loadbalancing =
relationship between network accesses, they serve difference purpose, don=
=A1=AFt mix them.

Thanks,

 

    David

 

On 03/07/2017 10:52, Qin Wu wro= te:

Hi, All:

The v-(02) of RFC8049bis has ju= st been posted,

https://datatracker.ietf.org/doc= /draft-wu-l3sm-rfc8049bis/

thanks Jan and David for valuab= le comments and input, the main changes include:

1.Specify what type of IPv6 address in the model for IPv6 connec= tion? link-local global

2.Specify provider address and a list of start-end addresses fro= m provider address

3.remove redundant parameters such as deny-any-except and permit= -any-except under cloud-access?

4. Add a few text to clarify wh= at the site is in section 6.3

5. Add a few text to clarify wh= y having customer-name.

6. Fixed two typos pointed by J= an recently.

 

Talking with L3Sm design team, = we believe how information is communicated by SP to the customer is beyond = the scope of

RFC8049 has already been clarified in section 6.6, 2nd= paragraph, section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.= 12.2.2,4th paragraph.

 

Regarding whether AS number und= er BGP protocol is supposed to be the customer's AS number or the SP's AS n= umber, we think AS number as

part of BGP protocol related pa= rameters are applied to provider to customer boundary, therefore the answer= is depending on

how the management model is administered.

 

As Jan pointed out, we still have some new mandatory f= ields introduced in v-(02) haven=A1=AFt been reflected in the examples. But= he is okay with the current shape.

Please review these changes, let us know if there is a= ny additional comments.

 

Regards!

Qin (on behalf of team)

 

 




_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm




-- 
David Ball
<davibal=
l@cisco.com>
--_000_B8F9A780D330094D99AF023C5877DABA9A9A7FBDnkgeml513mbxchi_-- From nobody Mon Jul 10 06:48:53 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F96131785 for ; Mon, 10 Jul 2017 06:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 tN1FGjUjgWCw for ; Mon, 10 Jul 2017 06:48:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7254E12EAFF for ; Mon, 10 Jul 2017 06:48:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQU30193; Mon, 10 Jul 2017 13:48:48 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Jul 2017 14:48:47 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 10 Jul 2017 21:48:44 +0800 From: Qin Wu To: David Ball , "l3sm@ietf.org" Thread-Topic: [L2sm] [L3sm] Followup of RFC8049bis Thread-Index: AdLz4gQczWlV+rrbRBePS8Ez8xfWvQBX1HKAADLs4QAA3YGr4A== Date: Mon, 10 Jul 2017 13:48:43 +0000 Message-ID: References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <79d0d82a-f810-0ca5-7f43-003f7f6c47a8@cisco.com> In-Reply-To: <79d0d82a-f810-0ca5-7f43-003f7f6c47a8@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.596385C0.01E5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a8b8544ba80cf5aafd6924f07e596d40 Archived-At: Subject: Re: [L3sm] [L2sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 13:48:52 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IERhdmlkIEJhbGwgW21haWx0bzpkYXZpYmFsbEBj aXNjby5jb21dIA0Kt6LLzcqxvOQ6IDIwMTfE6jfUwjbI1SAyMDowNQ0KytW8/sjLOiBRaW4gV3U7 IGwzc21AaWV0Zi5vcmcNCtb3zOI6IFJlOiBbTDJzbV0gW0wzc21dIEZvbGxvd3VwIG9mIFJGQzgw NDliaXMNCg0KSGkgUWluLA0KDQpPbiAwNS8wNy8yMDE3IDEyOjQ2LCBEYXZpZCBCYWxsIHdyb3Rl Og0KPiA2LiBBZGRyZXNzZWQgaW4gdGhlIG5ldyBkcmFmdA0KDQpUaGlzIG9uZSB3YXMgYWJvdXQg dGhlIGR1cGxpY2F0aW9uIG9mIGF1dGhvcml6ZWQvZGVuaWVkIHNpdGVzIHVuZGVyIHRoZSBjbG91 ZCBhY2Nlc3MgLSBJIGxvb2tlZCBtb3JlIGNhcmVmdWxseSBhbmQgSSB0aGluayB5b3UgbWF5IGhh dmUgZGVsZXRlZCB0aGUgd3Jvbmcgb25lcz8gIFRoZSBuZXcgZHJhZnQgbm93IGhhcyBhIGNob2lj ZSAibGlzdC1mbGF2b3IiIHRoYXQgb25seSBoYXMgb25lIGNhc2UuLi4NCltRaW5dOiBUaGUgZ29h bCBpcyB0byBkZWxldGUgdGhlIGR1cGxpY2F0ZWQgb25lcywgaWYgeW91IHRoaW5rIHdlIHNob3Vs ZCBrZWVwIGxpc3QtZmxhdm9yLCB0aGlzIGlzIGZpbmUgdG8gbWUgYW5kIHdlIGNhbiBmaXggdGhp cyBpbiBuZXh0IHZlcnNpb24uDQoNCiAgICAgRGF2aWQNCg0KLS0NCkRhdmlkIEJhbGwNCjxkYXZp YmFsbEBjaXNjby5jb20+DQoNCg== From nobody Mon Jul 10 07:01:37 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B6613178F for ; Mon, 10 Jul 2017 07:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 7luxnPnV81CN for ; Mon, 10 Jul 2017 07:01:34 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55187131785 for ; Mon, 10 Jul 2017 07:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1052; q=dns/txt; s=iport; t=1499695294; x=1500904894; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=0K2PnvnnDBMfBxSlbEX/s85fI/H3a+W1ADptqvqZMUA=; b=WFsMbrsmWiP7XYqNErkUS9DBS6WYILizq3cjrFdb0jhLeWyg4yZcSnfi 2VZOuNvW/k+Xa+aWCfAzGiYzo3iTpxJkEWOEAVNgcO2FC+jTaUEZI94UW uEkpLSiA8VfREddl7MbzYieOYmF9hWWzY8NQtS6ts3ip5QkZTfniLJmRB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAgA1h2NZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhVKDcIsMkHeWBIIRhhwCg2UWAQIBAQEBAQEBayiFGQEFIw8BBVEJAg4?= =?us-ascii?q?KAgIjAwICRhEGAQwGAgEBiiuNCp1jgiaLQQEBAQEBAQEDAQEBAQEBASGBC4Idg?= =?us-ascii?q?0yCDIJ5gTyGQYJhAQSJUYhbjHKUCosmhnyMaIhYJgMugQoxIQgbFUmFH4F4Pza?= =?us-ascii?q?IZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,340,1496102400"; d="scan'208";a="655992262" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2017 14:01:32 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6AE1Vx4027801; Mon, 10 Jul 2017 14:01:31 GMT To: Qin Wu , "l3sm@ietf.org" References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <79d0d82a-f810-0ca5-7f43-003f7f6c47a8@cisco.com> From: David Ball Message-ID: <8dd692d3-6c56-95c8-f6df-95469731d4fb@cisco.com> Date: Mon, 10 Jul 2017 15:01:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [L3sm] [L2sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 14:01:37 -0000 Hi Qin, It looked to me like list-flavor was the new one and authorized/denied sites were the older ones that should have been deleted, but you probably know the history better than me here... David On 10/07/2017 14:48, Qin Wu wrote: > -----é‚źä»¶ćŽŸä»¶----- > ć‘ä»¶äșș: David Ball [mailto:daviball@cisco.com] > ć‘é€æ—¶é—Ž: 2017ćčŽ7月6æ—„ 20:05 > 收件äșș: Qin Wu; l3sm@ietf.org > 䞻鹘: Re: [L2sm] [L3sm] Followup of RFC8049bis > > Hi Qin, > > On 05/07/2017 12:46, David Ball wrote: >> 6. Addressed in the new draft > This one was about the duplication of authorized/denied sites under the cloud access - I looked more carefully and I think you may have deleted the wrong ones? The new draft now has a choice "list-flavor" that only has one case... > [Qin]: The goal is to delete the duplicated ones, if you think we should keep list-flavor, this is fine to me and we can fix this in next version. > > David > > -- > David Ball > > -- David Ball From nobody Tue Jul 11 04:09:59 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F6112EC3F for ; Tue, 11 Jul 2017 04:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.491 X-Spam-Level: X-Spam-Status: No, score=-14.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 h9bB5xR9JwgT for ; Tue, 11 Jul 2017 04:09:53 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86978128A32 for ; Tue, 11 Jul 2017 04:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61798; q=dns/txt; s=iport; t=1499771392; x=1500980992; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=iBRW/NFMlGgoquQ+sNTcoA3YfSrwvLW1E/D8gzgenZU=; b=SbSD/0ac8Ze4aDKtCy/5JWPkzWE6tx5FDK9KD4wy/JLWREU4OdrsefXA tz4aGymUjintaEW91LHVUJO8edrT1az5dlxnTyUfM4h59wkcfcQqJqBUb 2+TaSZhjqcIk+cxu8RndSViGXowVK2XXsFc8jbhqHajHexSCOm1OrCyAF Q=; X-IronPort-AV: E=Sophos;i="5.40,346,1496102400"; d="scan'208,217";a="656012576" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2017 11:09:51 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6BB9orU022688; Tue, 11 Jul 2017 11:09:50 GMT To: Qin Wu , "l3sm@ietf.org" Cc: "Benoit Claise (bclaise)" , "adrian@olddog.co.uk" References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> From: David Ball Message-ID: <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> Date: Tue, 11 Jul 2017 12:09:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F824894AA884F00CA3BD9B6F" Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 11:09:57 -0000 This is a multi-part message in MIME format. --------------F824894AA884F00CA3BD9B6F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Qin, I'm now really confused again about issue 1. You point to text in section 6 that concerns a small number of specific leaves in the model; but my question is about the scope of the model as a whole. In an answer to another issue, you said: "In Theory, both customer and provider can use this model parameter to talk to each other." - that seems to contradict Kenichi's answer to my original question. In essence, my question is about the scope of the model *as a whole*. Is the model intended to include: * All information that needs to be exchanged between the SP and the Customer? * Only information requested by the customer to the SP? * Something else? If so, what? I think this may be the source of confusion for a number of the other issues so I'll hold off on responding about those until we've addressed this. I don't have a strong opinion on the answer but I would really like the scope of the model to be clearly stated so that we can check the rest of the content against the scope. Currently it seems to be closest to the second one (and that was what I said in my original email and what Kenichi confirmed), but your reply seems to suggest something different. David On 10/07/2017 14:47, Qin Wu wrote: > > *ć‘ä»¶äșș:*David Ball [mailto:daviball@cisco.com] > *ć‘é€æ—¶é—Ž:*2017ćčŽ7月5æ—„19:47 > *收件äșș:*Qin Wu; l3sm@ietf.org; l2sm@ietf.org > *抄送:*Benoit Claise (bclaise); adrian@olddog.co.uk > *䞻鹘:*Re: [L3sm] Followup of RFC8049bis > > Thanks Qin. > > I thought it might be useful to summarize the discussion on each of my > original questions so far. In general, I imagine that if I had a > question, other readers might have the same question too, so even if > we have answered the question on the thread, I think it is good to > provide the clarification in the text as well. > > 1. You mention below that you think this is already described in > section 6.6 and 6.12. However, the fact that the model only > covers information requested by the customer to the SP is a key > aspect of the model that is critical to the reader's > understanding, so I think it needs to be explained much more > clearly, and much earlier in the document i.e. in section 5. > > [Qin]: You need to read carefully, it clearly explain what kind > of information responded by SP to the Customer is not in the scope of > this document. For most of other information, it doesn’t require SP to > respond back to Customer. > > See section 6.6 , 3^rd paragraph: > > “If a constraint is too strict and cannot be fulfilled, the management > system MUST NOT provision the site and SHOULD provide relevant > information to the user.” > > See section 6.6.3 2^nd paragraph ,1^st bullet: > > “If the "strict" leaf is equal to "false"(default) and if the > requested media type cannot be fulfilled, the management system can > select another media type. The supported media types SHOULD be > communicated by the SP to the customer via a mechanism that is out of > scope for this document.” > > See section 6.12.2.2,4th paragraph: > > “some constraints may not be completely fulfilled by the SP; in this > case, the SP should advise the customer about the limitations. How > this communication is done is out of scope for this document.” > > 2. As far as I saw, you only added one sentence about this - I think > a bit more is needed! In fact I wonder if we are even all on the > same page in the emails, since your answer didn't seem to quite > align with what Kenichi and Stephane said. > > [Qin]: Site notion has been well clarified in the document: > > “ A site has several characteristics: > > o Unique identifier (site-id): uniquely identifies the site within > > the overall network infrastructure. The identifier is a string > > that allows any encoding for the local administration of the VPN > > service. > > o Locations (locations): site location information that allows easy > > retrieval of information from the nearest available resources. A > > site may be composed of multiple locations. > > o Devices (devices): allows the customer to request one or more > > customer premises equipment entities from the SP for a particular > > site. > > o Management (management): defines the type of management for the > > site -- for example, co-managed, customer-managed, or provider- > > managed. See Section 6.10 > . > > o Site network accesses (site-network-accesses): defines the list of > > network accesses associated with the sites, and their properties > > -- especially bearer, connection, and service parameters. > > ” > > I add one sentence to get consist with this. The proposed changes have > got approved by Stepane and Kenichi already before posting to the list. > > 3. I didn't see any text added to address this - and again, I'm not > sure we're all on the same page yet. Kenichi agreed that there is > no technical difference between using SubVPN and using multiple > sites, although obviously this is related to question 2. At the > very least, the ambiguity in the existing text should be fixed! > > [Qin]:I think the key difference between subVPN and multi-VPN is > whether they share the same bearer. It is clarified in the section 6.5.1.3 > > “ > > It is similar to having separate sites, but in this case the customer > > wants to share some physical components while maintaining strong > communication isolation between the affiliates. > > ” > > Physical components are referred to the bearer. > > I think this is sufficient. If you think we should further limit > subVPN to the same bearer and same CPE, please let me know. > > 4. Addressed in the new draft > 5. Conclusion is that using a single VPN service for multiple clouds > is technically the same as using a separate VPN service for each > cloud, but it might be easier operationally. This needs to be > explained in the draft. > > [Qin]: I believe using a separate VPN service for each cloud is not in > the scope of this document. This draft clear explained to support > public cloud access, support private cloud access with a single VPN > service. > > 6. Addressed in the new draft > 7. Can be addressed with an augment, so no change needed > > [Qin]: Agree, do you think section 6.1 “Features and Augmentation” is > sufficient to address your comment with any text change. > > 8. You agreed to add some additional explanation about MTU, but I > didn't see any changes in the draft? > > [Qin]:Addressed in the previous version which address Jan’s comments, See > > “ > > leaf svc-mtu { > > type uint16; > > units bytes; > > mandatory true; > > description > > "MTU at service level. If the service is IP, > > it refers to the IP MTU. If CsC is enabled, > > the requested 'svc-mtu' leaf will refer to the > > MPLS MTU and not to the IP MTU. "; > > ” > > 9. Conclusion was that max routes per VPN might be useful but hard to > implement, so no change needed. > 10. Per-VPN QoS policy can be achieved in most cases using the > target-sites option - need to add text to explain this > > [Qin]: Okay. > > 11. Can specify different performance objectives by using more > classes, no change needed > 12. I still don't understand what the SP is supposed to do in a > multipoint case where end-to-end is true. Actually, even in a P2P > case, there is a problem if the guaranteed end-to-end bandwidth is > specified differently at each end. Should the SP take the higher > or lower value? > > [Qin]: I think this depends on the SP's implementation of the service. > > 13. Routing: > 1. Agreed no change needed > 2. Agreed no change needed > 3. Concluded that other parameters (timers etc) are set by the SP > and communicated outside of the model, not requested by the > customer. Need to explain this in the text. > > [Qin]: Okay. > > 4. Addressed in the new draft > 5. I did not understand your comment about the BGP AS number > below - all the attributes in the model are applied at the > customer to SP boundary, but it still needs to be clarified > whether it is the customer's or SP's AS number. Actually > given that the model is only covering what the customer > requests, I guess it would always be the customer's AS number > (since the customer wouldn't need to request the SP's AS > number, that would be provided by the SP to the customer, > which is outside the scope of the model). So I think the text > should clarify that this is the customer's AS number. > > [Qin] Not sure we should distinct the parameter used > by customer to talk to provider from the parameter used by provider to > talk to customer. In Theory, both customer and provider can use this > model parameter to talk to each other. I would like to hear other’s > opinion. > > 6. Concluded that other parameters (timers etc) are set by the SP > and communicated outside of the model, not requested by the > customer. Need to explain this in the text. > > [Qin]: Okay. > > 7. Number of BGP sessions - SP decides and tells the customer, so > this is outside the scope. Need to clarify in the text. > > [Qin]: Will check this. > > 8. Model does not cover the case of eBGP multihop between > loopbacks - need to mention this in the text. > > [Qin]: I am not sure we should enumerate all the cases the > model doesn’t support. It is no-ending. This model is just a base model. > > 9. Agreed no change needed > 13. I didn't see an answer from anyone on why the BFD parameters can > only be specified per access link. It seems useful to me to allow > them to be specified per site too, like many other attributes. > > [Qin]: Please provide your use case. Not sure we should add this. On > the other hand, if there is a real use case, it can be added through > augmentation. > > 15. Connection Addressing: > 1. I saw you added the provider address and mask to the model for > the DHCP and DHCP relay cases - but if the model is only > covering information requested by the customer, then this > doesn't seem right. Instead, the text should explain that > they are supplied by the SP and thus are outside the scope of > the model. > > [Qin]: You set a pitfall for us to jump,J, but I have > clarified this to you at the beginning. I would like to hear what L3SM > Design Team think about this? > > 2. Addressed in the new draft - customer can request either a > number of addresses or an explicit list of address ranges. > 3. Agreed no change needed > 4. I saw you added a leaf for this, but I'm not sure that's quite > right. I'm not an IPv6 expert, but I thought LL addresses are > always there; my question was not "LL addresses or global > addresses?", it was "LL addresses only, or both LL and global > addresses?". If it's LL only, then I don't think any of the > other options apply - there is no need for static addresses, > DHCP or SLAAC if the link only uses LL addresses. > > [Qin]:not sure one address can be both LL and global address at > the same time, I would suggest to remove this parameter if this > introduce confusion. > > 16. Kenichi agreed there is an issue here, but I didn't see any fix in > the new draft? > > [Qin]: It is left over and will fix this. > > 17. Not sure we reached a conclusion on this one... > > [Qin]: Metric defined in this model is used for routing state > calculation and path selection while access priority defines defines a > preference for a particular access and decide primary/backup or > loadbalancing relationship between network accesses, they serve > difference purpose, don’t mix them. > > Thanks, > > David > > On 03/07/2017 10:52, Qin Wu wrote: > > Hi, All: > > The v-(02) of RFC8049bis has just been posted, > > https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ > > thanks Jan and David for valuable comments and input, the main > changes include: > > 1.Specify what type of IPv6 address in the model for IPv6 > connection? link-local global > > 2.Specify provider address and a list of start-end addresses from > provider address > > 3.remove redundant parameters such as deny-any-except and > permit-any-except under cloud-access? > > 4. Add a few text to clarify what the site is in section 6.3 > > 5. Add a few text to clarify why having customer-name. > > 6. Fixed two typos pointed by Jan recently. > > Talking with L3Sm design team, we believe how information is > communicated by SP to the customer is beyond the scope of > > RFC8049 has already been clarified in section 6.6, 2nd paragraph, > section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section > 6.12.2.2,4th paragraph. > > Regarding whether AS number under BGP protocol is supposed to be > the customer's AS number or the SP's AS number, we think AS number as > > part of BGP protocol related parameters are applied to provider to > customer boundary, therefore the answer is depending on > > how the management model is administered. > > As Jan pointed out, we still have some new mandatory fields > introduced in v-(02) haven’t been reflected in the examples. But > he is okay with the current shape. > > Please review these changes, let us know if there is any > additional comments. > > Regards! > > Qin (on behalf of team) > > > > > _______________________________________________ > > L3sm mailing list > > L3sm@ietf.org > > https://www.ietf.org/mailman/listinfo/l3sm > > > > -- > David Ball > -- David Ball --------------F824894AA884F00CA3BD9B6F Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Qin,

I'm now really confused again about issue 1.  You point to text in section 6 that concerns a small number of specific leaves in the model; but my question is about the scope of the model as a whole.  In an answer to another issue, you said: "In Theory, both customer and provider can use this model parameter to talk to each other." - that seems to contradict Kenichi's answer to my original question.

In essence, my question is about the scope of the model as a whole.  Is the model intended to include:
  • All information that needs to be exchanged between the SP and the Customer?
  • Only information requested by the customer to the SP?
  • Something else?  If so, what?

I think this may be the source of confusion for a number of the other issues so I'll hold off on responding about those until we've addressed this.  I don't have a strong opinion on the answer but I would really like the scope of the model to be clearly stated so that we can check the rest of the content against the scope.  Currently it seems to be closest to the second one (and that was what I said in my original email and what Kenichi confirmed), but your reply seems to suggest something different.


    David



On 10/07/2017 14:47, Qin Wu wrote:

ć‘ä»¶äșș: David Ball [mailto:daviball@cisco.com]
ć‘é€æ—¶é—Ž: 2017ćčŽ7月5æ—„ 19:47
收件äșș: Qin Wu; l3sm@ietf.org; l2sm@ietf.org
抄送: Benoit Claise (bclaise); adrian@olddog.co.uk
䞻鹘: Re: [L3sm] Followup of RFC8049bis

 

Thanks Qin.

I thought it might be useful to summarize the discussion on each of my original questions so far.  In general, I imagine that if I had a question, other readers might have the same question too, so even if we have answered the question on the thread, I think it is good to provide the clarification in the text as well.

  1. You mention below that you think this is already described in section 6.6 and 6.12.  However, the fact that the model only covers information requested by the customer to the SP is a key aspect of the model that is critical to the reader's understanding, so I think it needs to be explained much more clearly, and much earlier in the document i.e. in section 5.

      [Qin]: You need to read carefully, it clearly explain what kind of information responded by SP to the Customer is not in the scope of this document. For most of other information, it doesn’t require SP to respond back to Customer.

See section 6.6 , 3rd paragraph:

“If a constraint is too strict and cannot be fulfilled, the management system MUST NOT provision the site and SHOULD provide relevant information to the user.”

See section 6.6.3 2nd paragraph ,1st bullet:

“If the "strict" leaf is equal to "false"(default) and if the requested media type cannot be fulfilled, the management system can select another media type.  The supported media types SHOULD be communicated by the SP to the customer via a mechanism that is out of scope for this document.”

See section 6.12.2.2,4th paragraph:

“some constraints may not be completely fulfilled by the SP; in this case, the SP should advise the customer about the limitations.  How this communication is done is out of scope for this document.”

  1. As far as I saw, you only added one sentence about this - I think a bit more is needed!  In fact I wonder if we are even all on the same page in the emails, since your answer didn't seem to quite align with what Kenichi and Stephane said.

[Qin]: Site notion has been well clarified in the document:

“   A site has several characteristics:

 

   o  Unique identifier (site-id): uniquely identifies the site within

      the overall network infrastructure.  The identifier is a string

      that allows any encoding for the local administration of the VPN

      service.

 

   o  Locations (locations): site location information that allows easy

      retrieval of information from the nearest available resources.  A

      site may be composed of multiple locations.

 

   o  Devices (devices): allows the customer to request one or more

      customer premises equipment entities from the SP for a particular

      site.

 

   o  Management (management): defines the type of management for the

      site -- for example, co-managed, customer-managed, or provider-

      managed.  See Section 6.10.

 

   o  Site network accesses (site-network-accesses): defines the list of

      network accesses associated with the sites, and their properties

      -- especially bearer, connection, and service parameters.

”

I add one sentence to get consist with this. The proposed changes have got approved by Stepane and Kenichi already before posting to the list.

  1. I didn't see any text added to address this - and again, I'm not sure we're all on the same page yet.  Kenichi agreed that there is no technical difference between using SubVPN and using multiple sites, although obviously this is related to question 2.  At the very least, the ambiguity in the existing text should be fixed!

[Qin]:I think the key difference between subVPN and multi-VPN is whether they share the same bearer. It is clarified in the section 6.5.1.3

“

It is similar to having separate sites, but in this case the customer

wants to share some physical components while maintaining strong communication isolation between the affiliates.

”

Physical components are referred to the bearer.

I think this is sufficient. If you think we should further limit subVPN to the same bearer and same CPE, please let me know.

  1. Addressed in the new draft
  2. Conclusion is that using a single VPN service for multiple clouds is technically the same as using a separate VPN service for each cloud, but it might be easier operationally.  This needs to be explained in the draft.

[Qin]: I believe using a separate VPN service for each cloud is not in the scope of this document. This draft clear explained to support public cloud access, support private cloud access with a single VPN service.

  1. Addressed in the new draft
  2. Can be addressed with an augment, so no change needed
[Qin]: Agree, do you think section 6.1 “Features and Augmentation” is sufficient to address your comment with any text change.
  1. You agreed to add some additional explanation about MTU, but I didn't see any changes in the draft?

[Qin]:Addressed in the previous version which address Jan’s comments, See

“

     leaf svc-mtu { 

       type uint16; 

       units bytes; 

       mandatory true; 

       description 

        "MTU at service level. If the service is IP, 

         it refers to the IP MTU. If CsC is enabled, 

         the requested 'svc-mtu' leaf will refer to the 

         MPLS MTU and not to the IP MTU. ";

”

  1. Conclusion was that max routes per VPN might be useful but hard to implement, so no change needed.
  2. Per-VPN QoS policy can be achieved in most cases using the target-sites option - need to add text to explain this

[Qin]: Okay.

  1. Can specify different performance objectives by using more classes, no change needed
  2. I still don't understand what the SP is supposed to do in a multipoint case where end-to-end is true.  Actually, even in a P2P case, there is a problem if the guaranteed end-to-end bandwidth is specified differently at each end.  Should the SP take the higher or lower value?
[Qin]: I think this depends on the SP's implementation of the service.
  1. Routing:
    1. Agreed no change needed
    2. Agreed no change needed
    3. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer.  Need to explain this in the text.

                    [Qin]: Okay.

    1. Addressed in the new draft
    2. I did not understand your comment about the BGP AS number below - all the attributes in the model are applied at the customer to SP boundary, but it still needs to be clarified whether it is the customer's or SP's AS number.  Actually given that the model is only covering what the customer requests, I guess it would always be the customer's AS number (since the customer wouldn't need to request the SP's AS number, that would be provided by the SP to the customer, which is outside the scope of the model).  So I think the text should clarify that this is the customer's AS number.

                [Qin] Not sure we should distinct the parameter used by customer to talk to provider from the parameter used by provider to talk to customer. In Theory, both customer and provider can use this model    parameter to talk to each other. I would like to hear other’s opinion.

    1. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer.  Need to explain this in the text.

                  [Qin]: Okay.

    1. Number of BGP sessions - SP decides and tells the customer, so this is outside the scope.  Need to clarify in the text.

              [Qin]: Will check this.

    1. Model does not cover the case of eBGP multihop between loopbacks - need to mention this in the text.

          [Qin]: I am not sure we should enumerate all the cases the model doesn’t support. It is no-ending. This model is just a base model.

    1. Agreed no change needed
  1. I didn't see an answer from anyone on why the BFD parameters can only be specified per access link.  It seems useful to me to allow them to be specified per site too, like many other attributes.

[Qin]: Please provide your use case. Not sure we should add this. On the other hand, if there is a real use case, it can be added through augmentation.

  1. Connection Addressing:
    1. I saw you added the provider address and mask to the model for the DHCP and DHCP relay cases - but if the model is only covering information requested by the customer, then this doesn't seem right.  Instead, the text should explain that they are supplied by the SP and thus are outside the scope of the model.

             [Qin]: You set a pitfall for us to jump,J, but I have clarified this to you at the beginning. I would like to hear what L3SM Design Team think about this?

    1. Addressed in the new draft - customer can request either a number of addresses or an explicit list of address ranges.
    2. Agreed no change needed
    3. I saw you added a leaf for this, but I'm not sure that's quite right.  I'm not an IPv6 expert, but I thought LL addresses are always there; my question was not "LL addresses or global addresses?", it was "LL addresses only, or both LL and global addresses?".  If it's LL only, then I don't think any of the other options apply - there is no need for static addresses, DHCP or SLAAC if the link only uses LL addresses.

       [Qin]:not sure one address can be both LL and global address at the same time, I would suggest to remove this parameter if this introduce confusion.

  1. Kenichi agreed there is an issue here, but I didn't see any fix in the new draft?

    [Qin]: It is left over and will fix this.

  1. Not sure we reached a conclusion on this one...
  [Qin]: Metric defined in this model is used for routing state calculation and path selection while access priority defines defines a preference for a particular access and decide primary/backup or loadbalancing relationship between network accesses, they serve difference purpose, don’t mix them.

Thanks,

 

    David

 

On 03/07/2017 10:52, Qin Wu wrote:

Hi, All:

The v-(02) of RFC8049bis has just been posted,

https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/

thanks Jan and David for valuable comments and input, the main changes include:

1.Specify what type of IPv6 address in the model for IPv6 connection? link-local global

2.Specify provider address and a list of start-end addresses from provider address

3.remove redundant parameters such as deny-any-except and permit-any-except under cloud-access?

4. Add a few text to clarify what the site is in section 6.3

5. Add a few text to clarify why having customer-name.

6. Fixed two typos pointed by Jan recently.

 

Talking with L3Sm design team, we believe how information is communicated by SP to the customer is beyond the scope of

RFC8049 has already been clarified in section 6.6, 2nd paragraph, section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.12.2.2,4th paragraph.

 

Regarding whether AS number under BGP protocol is supposed to be the customer's AS number or the SP's AS number, we think AS number as

part of BGP protocol related parameters are applied to provider to customer boundary, therefore the answer is depending on

how the management model is administered.

 

As Jan pointed out, we still have some new mandatory fields introduced in v-(02) haven’t been reflected in the examples. But he is okay with the current shape.

Please review these changes, let us know if there is any additional comments.

 

Regards!

Qin (on behalf of team)

 

 




_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm



-- 
David Ball
<daviball@cisco.com>

-- 
David Ball
<daviball@cisco.com>
--------------F824894AA884F00CA3BD9B6F-- From nobody Wed Jul 12 01:55:04 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5159712EC3B for ; Wed, 12 Jul 2017 01:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dpIInqESElgw for ; Wed, 12 Jul 2017 01:54:59 -0700 (PDT) Received: from post-send.kddi.com (athena2.kddi.com [27.90.165.195]) by ietfa.amsl.com (Postfix) with ESMTP id 973E312708C for ; Wed, 12 Jul 2017 01:54:58 -0700 (PDT) Received: from LTMC2122.kddi.com (LTMC2122.kddi.com [10.206.0.63]) by post-send.kddi.com (KDDI Mail) with ESMTP id 85E4EE0023; Wed, 12 Jul 2017 17:54:57 +0900 (JST) Received: from LTMC2145.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2122.kddi.com with ESMTP; Wed, 12 Jul 2017 17:54:57 +0900 Received: from LTMC2145.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 5E1C93A006B; Wed, 12 Jul 2017 17:54:57 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2145.kddi.com (Postfix) with ESMTP id 52B133A0065; Wed, 12 Jul 2017 17:54:57 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v6C8suxq029059; Wed, 12 Jul 2017 17:54:57 +0900 Received: from LTMC2151.kddi.com.mid_23574377 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v6C8itcX015651; Wed, 12 Jul 2017 17:44:55 +0900 X-SA-MID: 23574377 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Wed, 12 Jul 2017 17:44:55 +0900 From: "Ogaki, Kenichi" To: "'David Ball'" , "'Qin Wu'" , Cc: "'Benoit Claise \(bclaise\)'" , References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> In-Reply-To: <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> Date: Wed, 12 Jul 2017 17:44:54 +0900 Message-ID: <000301d2faeb$22864890$6792d9b0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: ja Thread-Index: AQFt7Pfdo0zsTznSH6gPl8UfrToyiwF/DcMJAdAfHcMBM/6/AKL1WB9Q X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 08:55:02 -0000 Hi David, >* All information that needs to be exchanged between the SP and the = Customer? >* Only information requested by the customer to the SP? >* Something else? If so, what? I believe your second one is closer to the rational of this whole model, = but the customer requests not information, but vpn service provisioning. Also, the SP needs all information required to provision the vpn = service, when a customer requests a vpn service. In that sense, we may be able to understand your first one also implies = this. Anyway, does the following paragraph in section 5 cover the rational? The idea of the L3 IP VPN service model is to propose an abstracted interface between customers and network operators to manage configuration of components of an L3VPN service. A typical scenario would be to use this model as an input for an orchestration layer that will be responsible for translating it to an orchestrated configuration of network elements that will be part of the service. I think Qin's example is a complementary but a necessary procedure to = utilize this model. All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball Sent: Tuesday, July 11, 2017 8:10 PM To: Qin Wu; l3sm@ietf.org Cc: Benoit Claise (bclaise); adrian@olddog.co.uk Subject: Re: [L3sm] Followup of RFC8049bis Hi Qin, I'm now really confused again about issue 1. You point to text in = section 6 that concerns a small number of specific leaves in the model; = but my question is about the scope of the model as a whole. In an = answer to another issue, you said: "In Theory, both customer and = provider can use this model parameter to talk to each other." - that = seems to contradict Kenichi's answer to my original question. In essence, my question is about the scope of the model as a whole. Is = the model intended to include:=20 * All information that needs to be exchanged between the SP and the = Customer? * Only information requested by the customer to the SP? * Something else? If so, what? I think this may be the source of confusion for a number of the other = issues so I'll hold off on responding about those until we've addressed = this. I don't have a strong opinion on the answer but I would really = like the scope of the model to be clearly stated so that we can check = the rest of the content against the scope. Currently it seems to be = closest to the second one (and that was what I said in my original email = and what Kenichi confirmed), but your reply seems to suggest something = different. David On 10/07/2017 14:47, Qin Wu wrote: =E5=8F=91=E4=BB=B6=E4=BA=BA: David Ball [mailto:daviball@cisco.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B47=E6=9C=885=E6=97=A5 = 19:47 =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu; l3sm@ietf.org; l2sm@ietf.org =E6=8A=84=E9=80=81: Benoit Claise (bclaise); adrian@olddog.co.uk =E4=B8=BB=E9=A2=98: Re: [L3sm] Followup of RFC8049bis =20 Thanks Qin. I thought it might be useful to summarize the discussion on each of my = original questions so far. In general, I imagine that if I had a = question, other readers might have the same question too, so even if we = have answered the question on the thread, I think it is good to provide = the clarification in the text as well. 1. You mention below that you think this is already described in = section 6.6 and 6.12. However, the fact that the model only covers = information requested by the customer to the SP is a key aspect of the = model that is critical to the reader's understanding, so I think it = needs to be explained much more clearly, and much earlier in the = document i.e. in section 5. [Qin]: You need to read carefully, it clearly explain what kind = of information responded by SP to the Customer is not in the scope of = this document. For most of other information, it doesn=E2=80=99t require = SP to respond back to Customer. See section 6.6 , 3rd paragraph: =E2=80=9CIf a constraint is too strict and cannot be fulfilled, the = management system MUST NOT provision the site and SHOULD provide = relevant information to the user.=E2=80=9D See section 6.6.3 2nd paragraph ,1st bullet: =E2=80=9CIf the "strict" leaf is equal to "false"(default) and if the = requested media type cannot be fulfilled, the management system can = select another media type. The supported media types SHOULD be = communicated by the SP to the customer via a mechanism that is out of = scope for this document.=E2=80=9D See section 6.12.2.2,4th paragraph: =E2=80=9Csome constraints may not be completely fulfilled by the SP; in = this case, the SP should advise the customer about the limitations. How = this communication is done is out of scope for this document.=E2=80=9D 2. As far as I saw, you only added one sentence about this - I think a = bit more is needed! In fact I wonder if we are even all on the same = page in the emails, since your answer didn't seem to quite align with = what Kenichi and Stephane said. [Qin]: Site notion has been well clarified in the document: =E2=80=9C A site has several characteristics: =20 o Unique identifier (site-id): uniquely identifies the site within the overall network infrastructure. The identifier is a string that allows any encoding for the local administration of the VPN service. =20 o Locations (locations): site location information that allows easy retrieval of information from the nearest available resources. A site may be composed of multiple locations. =20 o Devices (devices): allows the customer to request one or more customer premises equipment entities from the SP for a particular site. =20 o Management (management): defines the type of management for the site -- for example, co-managed, customer-managed, or provider- managed. See Section 6.10 = . =20 o Site network accesses (site-network-accesses): defines the list = of network accesses associated with the sites, and their properties -- especially bearer, connection, and service parameters. =E2=80=9D I add one sentence to get consist with this. The proposed changes have = got approved by Stepane and Kenichi already before posting to the list.=20 3. I didn't see any text added to address this - and again, I'm not = sure we're all on the same page yet. Kenichi agreed that there is no = technical difference between using SubVPN and using multiple sites, = although obviously this is related to question 2. At the very least, = the ambiguity in the existing text should be fixed! [Qin]:I think the key difference between subVPN and multi-VPN is = whether they share the same bearer. It is clarified in the section = 6.5.1.3 =E2=80=9C It is similar to having separate sites, but in this case the customer wants to share some physical components while maintaining strong = communication isolation between the affiliates. =E2=80=9D Physical components are referred to the bearer. I think this is sufficient. If you think we should further limit subVPN = to the same bearer and same CPE, please let me know. 4. Addressed in the new draft 5. Conclusion is that using a single VPN service for multiple clouds is = technically the same as using a separate VPN service for each cloud, but = it might be easier operationally. This needs to be explained in the = draft. [Qin]: I believe using a separate VPN service for each cloud is not in = the scope of this document. This draft clear explained to support public = cloud access, support private cloud access with a single VPN service. 6. Addressed in the new draft 7. Can be addressed with an augment, so no change needed [Qin]: Agree, do you think section 6.1 =E2=80=9CFeatures and = Augmentation=E2=80=9D is sufficient to address your comment with any = text change. 8. You agreed to add some additional explanation about MTU, but I = didn't see any changes in the draft? [Qin]:Addressed in the previous version which address Jan=E2=80=99s = comments, See=20 =E2=80=9C leaf svc-mtu { =20 type uint16; =20 units bytes; =20 mandatory true; =20 description =20 "MTU at service level. If the service is IP, =20 it refers to the IP MTU. If CsC is enabled, =20 the requested 'svc-mtu' leaf will refer to the =20 MPLS MTU and not to the IP MTU. "; =E2=80=9D 9. Conclusion was that max routes per VPN might be useful but hard to = implement, so no change needed. 10. Per-VPN QoS policy can be achieved in most cases using the = target-sites option - need to add text to explain this [Qin]: Okay. 11. Can specify different performance objectives by using more classes, = no change needed 12. I still don't understand what the SP is supposed to do in a = multipoint case where end-to-end is true. Actually, even in a P2P case, = there is a problem if the guaranteed end-to-end bandwidth is specified = differently at each end. Should the SP take the higher or lower value? [Qin]: I think this depends on the SP's implementation of the service. 13. Routing:=20 1. Agreed no change needed 2. Agreed no change needed 3. Concluded that other parameters (timers etc) are set by the SP and = communicated outside of the model, not requested by the customer. Need = to explain this in the text. [Qin]: Okay. 4. Addressed in the new draft 5. I did not understand your comment about the BGP AS number below - = all the attributes in the model are applied at the customer to SP = boundary, but it still needs to be clarified whether it is the = customer's or SP's AS number. Actually given that the model is only = covering what the customer requests, I guess it would always be the = customer's AS number (since the customer wouldn't need to request the = SP's AS number, that would be provided by the SP to the customer, which = is outside the scope of the model). So I think the text should clarify = that this is the customer's AS number. [Qin] Not sure we should distinct the parameter used by = customer to talk to provider from the parameter used by provider to talk = to customer. In Theory, both customer and provider can use this model = parameter to talk to each other. I would like to hear other=E2=80=99s = opinion. 6. Concluded that other parameters (timers etc) are set by the SP and = communicated outside of the model, not requested by the customer. Need = to explain this in the text. [Qin]: Okay. 7. Number of BGP sessions - SP decides and tells the customer, so this = is outside the scope. Need to clarify in the text. [Qin]: Will check this. 8. Model does not cover the case of eBGP multihop between loopbacks - = need to mention this in the text. [Qin]: I am not sure we should enumerate all the cases the = model doesn=E2=80=99t support. It is no-ending. This model is just a = base model.=20 9. Agreed no change needed 13. I didn't see an answer from anyone on why the BFD parameters can = only be specified per access link. It seems useful to me to allow them = to be specified per site too, like many other attributes. [Qin]: Please provide your use case. Not sure we should add this. On = the other hand, if there is a real use case, it can be added through = augmentation. 15. Connection Addressing:=20 1. I saw you added the provider address and mask to the model for the = DHCP and DHCP relay cases - but if the model is only covering = information requested by the customer, then this doesn't seem right. = Instead, the text should explain that they are supplied by the SP and = thus are outside the scope of the model. [Qin]: You set a pitfall for us to jump,J, but I have = clarified this to you at the beginning. I would like to hear what L3SM = Design Team think about this? 2. Addressed in the new draft - customer can request either a number = of addresses or an explicit list of address ranges. 3. Agreed no change needed 4. I saw you added a leaf for this, but I'm not sure that's quite = right. I'm not an IPv6 expert, but I thought LL addresses are always = there; my question was not "LL addresses or global addresses?", it was = "LL addresses only, or both LL and global addresses?". If it's LL only, = then I don't think any of the other options apply - there is no need for = static addresses, DHCP or SLAAC if the link only uses LL addresses. [Qin]:not sure one address can be both LL and global address at = the same time, I would suggest to remove this parameter if this = introduce confusion. 16. Kenichi agreed there is an issue here, but I didn't see any fix in = the new draft? [Qin]: It is left over and will fix this. 17. Not sure we reached a conclusion on this one... [Qin]: Metric defined in this model is used for routing state = calculation and path selection while access priority defines defines a = preference for a particular access and decide primary/backup or = loadbalancing relationship between network accesses, they serve = difference purpose, don=E2=80=99t mix them. Thanks, =20 David =20 On 03/07/2017 10:52, Qin Wu wrote: Hi, All: The v-(02) of RFC8049bis has just been posted,=20 https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ thanks Jan and David for valuable comments and input, the main changes = include: 1.Specify what type of IPv6 address in the model for IPv6 connection? = link-local global 2.Specify provider address and a list of start-end addresses from = provider address 3.remove redundant parameters such as deny-any-except and = permit-any-except under cloud-access?=20 4. Add a few text to clarify what the site is in section 6.3 5. Add a few text to clarify why having customer-name. 6. Fixed two typos pointed by Jan recently. =20 Talking with L3Sm design team, we believe how information is = communicated by SP to the customer is beyond the scope of=20 RFC8049 has already been clarified in section 6.6, 2nd paragraph, = section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section = 6.12.2.2,4th paragraph. =20 Regarding whether AS number under BGP protocol is supposed to be the = customer's AS number or the SP's AS number, we think AS number as=20 part of BGP protocol related parameters are applied to provider to = customer boundary, therefore the answer is depending on=20 how the management model is administered. =20 As Jan pointed out, we still have some new mandatory fields introduced = in v-(02) haven=E2=80=99t been reflected in the examples. But he is okay = with the current shape. Please review these changes, let us know if there is any additional = comments. =20 Regards! Qin (on behalf of team) =20 =20 =09 =09 =09 =09 _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm =09 =09 =09 --=20 David Ball =20 --=20 David Ball =20 From nobody Wed Jul 12 02:33:22 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA5712EC15 for ; Wed, 12 Jul 2017 02:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1oG5288XiXQM for ; Wed, 12 Jul 2017 02:33:18 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C54126B72 for ; Wed, 12 Jul 2017 02:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16300; q=dns/txt; s=iport; t=1499851997; x=1501061597; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=PGsM0FSQ9wE/8hdtKIQ1eK15i1axeyS2M6bZdp44ODM=; b=KHwE8kGhzM1fsgwpRVf19halhfAFpHrvJAOnoetYcjarzUPqLKfcQf4h XJngn2Xla1UE8dG0uH2vhDNAvpK7nAlS5y8y6h3OsJ7K2DeAGlZfkXZnH n4pddHjI4xdRN/XV4hW8RiEOllD8KGSpicdHWPcvcS5Lb+owesDqFzhwR A=; X-IronPort-AV: E=Sophos;i="5.40,349,1496102400"; d="scan'208";a="654214475" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2017 09:33:16 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6C9XEkE006836; Wed, 12 Jul 2017 09:33:15 GMT To: "Ogaki, Kenichi" , "'Qin Wu'" , l3sm@ietf.org Cc: "'Benoit Claise (bclaise)'" , adrian@olddog.co.uk References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> <000301d2faeb$22864890$6792d9b0$@kddi.com> From: David Ball Message-ID: <42e2c5d8-05fa-65f2-52e4-ec2db62b0a6f@cisco.com> Date: Wed, 12 Jul 2017 10:33:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <000301d2faeb$22864890$6792d9b0$@kddi.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 09:33:21 -0000 Hi Kenichi, On 12/07/2017 09:44, Ogaki, Kenichi wrote: > Hi David, > >> * All information that needs to be exchanged between the SP and the Customer? >> * Only information requested by the customer to the SP? >> * Something else? If so, what? > I believe your second one is closer to the rational of this whole model, but the customer requests not information, but vpn service provisioning. Yes agreed, that is a better way of putting it. The model contains information that needs to be included in a customer's request to a SP for VPN service provisioning. > Also, the SP needs all information required to provision the vpn service, when a customer requests a vpn service. > In that sense, we may be able to understand your first one also implies this. Here I don't quite agree - the first one would also include information that the SP needs to give the customer in order for them to be able to use the service. If I understand correctly, that is not intended to be included in the yang model, right? > Anyway, does the following paragraph in section 5 cover the rational? > > The idea of the L3 IP VPN service model is to propose an abstracted > interface between customers and network operators to manage > configuration of components of an L3VPN service. A typical scenario > would be to use this model as an input for an orchestration layer > that will be responsible for translating it to an orchestrated > configuration of network elements that will be part of the service. To me, this paragraph does not clearly express that the information that needs to be passed from the SP to the customer is not in scope. I would like to see that stated explicitly, if that is indeed the intent. Thanks, David > > I think Qin's example is a complementary but a necessary procedure to utilize this model. > > All the best, > Kenichi > > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Tuesday, July 11, 2017 8:10 PM > To: Qin Wu; l3sm@ietf.org > Cc: Benoit Claise (bclaise); adrian@olddog.co.uk > Subject: Re: [L3sm] Followup of RFC8049bis > > Hi Qin, > > I'm now really confused again about issue 1. You point to text in section 6 that concerns a small number of specific leaves in the model; but my question is about the scope of the model as a whole. In an answer to another issue, you said: "In Theory, both customer and provider can use this model parameter to talk to each other." - that seems to contradict Kenichi's answer to my original question. > > In essence, my question is about the scope of the model as a whole. Is the model intended to include: > > * All information that needs to be exchanged between the SP and the Customer? > * Only information requested by the customer to the SP? > * Something else? If so, what? > > I think this may be the source of confusion for a number of the other issues so I'll hold off on responding about those until we've addressed this. I don't have a strong opinion on the answer but I would really like the scope of the model to be clearly stated so that we can check the rest of the content against the scope. Currently it seems to be closest to the second one (and that was what I said in my original email and what Kenichi confirmed), but your reply seems to suggest something different. > > > > > > David > > > > > On 10/07/2017 14:47, Qin Wu wrote: > > > ć‘ä»¶äșș: David Ball [mailto:daviball@cisco.com] > ć‘é€æ—¶é—Ž: 2017ćčŽ7月5æ—„ 19:47 > 收件äșș: Qin Wu; l3sm@ietf.org; l2sm@ietf.org > 抄送: Benoit Claise (bclaise); adrian@olddog.co.uk > 䞻鹘: Re: [L3sm] Followup of RFC8049bis > > > > Thanks Qin. > > I thought it might be useful to summarize the discussion on each of my original questions so far. In general, I imagine that if I had a question, other readers might have the same question too, so even if we have answered the question on the thread, I think it is good to provide the clarification in the text as well. > > 1. You mention below that you think this is already described in section 6.6 and 6.12. However, the fact that the model only covers information requested by the customer to the SP is a key aspect of the model that is critical to the reader's understanding, so I think it needs to be explained much more clearly, and much earlier in the document i.e. in section 5. > > [Qin]: You need to read carefully, it clearly explain what kind of information responded by SP to the Customer is not in the scope of this document. For most of other information, it doesn’t require SP to respond back to Customer. > > See section 6.6 , 3rd paragraph: > > “If a constraint is too strict and cannot be fulfilled, the management system MUST NOT provision the site and SHOULD provide relevant information to the user.” > > See section 6.6.3 2nd paragraph ,1st bullet: > > “If the "strict" leaf is equal to "false"(default) and if the requested media type cannot be fulfilled, the management system can select another media type. The supported media types SHOULD be communicated by the SP to the customer via a mechanism that is out of scope for this document.” > > See section 6.12.2.2,4th paragraph: > > “some constraints may not be completely fulfilled by the SP; in this case, the SP should advise the customer about the limitations. How this communication is done is out of scope for this document.” > > 2. As far as I saw, you only added one sentence about this - I think a bit more is needed! In fact I wonder if we are even all on the same page in the emails, since your answer didn't seem to quite align with what Kenichi and Stephane said. > > [Qin]: Site notion has been well clarified in the document: > > “ A site has several characteristics: > > > > o Unique identifier (site-id): uniquely identifies the site within > > the overall network infrastructure. The identifier is a string > > that allows any encoding for the local administration of the VPN > > service. > > > > o Locations (locations): site location information that allows easy > > retrieval of information from the nearest available resources. A > > site may be composed of multiple locations. > > > > o Devices (devices): allows the customer to request one or more > > customer premises equipment entities from the SP for a particular > > site. > > > > o Management (management): defines the type of management for the > > site -- for example, co-managed, customer-managed, or provider- > > managed. See Section 6.10 . > > > > o Site network accesses (site-network-accesses): defines the list of > > network accesses associated with the sites, and their properties > > -- especially bearer, connection, and service parameters. > > ” > > I add one sentence to get consist with this. The proposed changes have got approved by Stepane and Kenichi already before posting to the list. > > 3. I didn't see any text added to address this - and again, I'm not sure we're all on the same page yet. Kenichi agreed that there is no technical difference between using SubVPN and using multiple sites, although obviously this is related to question 2. At the very least, the ambiguity in the existing text should be fixed! > > [Qin]:I think the key difference between subVPN and multi-VPN is whether they share the same bearer. It is clarified in the section 6.5.1.3 > > “ > > It is similar to having separate sites, but in this case the customer > > wants to share some physical components while maintaining strong communication isolation between the affiliates. > > ” > > Physical components are referred to the bearer. > > I think this is sufficient. If you think we should further limit subVPN to the same bearer and same CPE, please let me know. > > 4. Addressed in the new draft > 5. Conclusion is that using a single VPN service for multiple clouds is technically the same as using a separate VPN service for each cloud, but it might be easier operationally. This needs to be explained in the draft. > > [Qin]: I believe using a separate VPN service for each cloud is not in the scope of this document. This draft clear explained to support public cloud access, support private cloud access with a single VPN service. > > 6. Addressed in the new draft > 7. Can be addressed with an augment, so no change needed > > [Qin]: Agree, do you think section 6.1 “Features and Augmentation” is sufficient to address your comment with any text change. > > 8. You agreed to add some additional explanation about MTU, but I didn't see any changes in the draft? > > [Qin]:Addressed in the previous version which address Jan’s comments, See > > “ > > leaf svc-mtu { > > type uint16; > > units bytes; > > mandatory true; > > description > > "MTU at service level. If the service is IP, > > it refers to the IP MTU. If CsC is enabled, > > the requested 'svc-mtu' leaf will refer to the > > MPLS MTU and not to the IP MTU. "; > > ” > > 9. Conclusion was that max routes per VPN might be useful but hard to implement, so no change needed. > 10. Per-VPN QoS policy can be achieved in most cases using the target-sites option - need to add text to explain this > > [Qin]: Okay. > > 11. Can specify different performance objectives by using more classes, no change needed > 12. I still don't understand what the SP is supposed to do in a multipoint case where end-to-end is true. Actually, even in a P2P case, there is a problem if the guaranteed end-to-end bandwidth is specified differently at each end. Should the SP take the higher or lower value? > > [Qin]: I think this depends on the SP's implementation of the service. > > 13. Routing: > > 1. Agreed no change needed > 2. Agreed no change needed > 3. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer. Need to explain this in the text. > > [Qin]: Okay. > > 4. Addressed in the new draft > 5. I did not understand your comment about the BGP AS number below - all the attributes in the model are applied at the customer to SP boundary, but it still needs to be clarified whether it is the customer's or SP's AS number. Actually given that the model is only covering what the customer requests, I guess it would always be the customer's AS number (since the customer wouldn't need to request the SP's AS number, that would be provided by the SP to the customer, which is outside the scope of the model). So I think the text should clarify that this is the customer's AS number. > > [Qin] Not sure we should distinct the parameter used by customer to talk to provider from the parameter used by provider to talk to customer. In Theory, both customer and provider can use this model parameter to talk to each other. I would like to hear other’s opinion. > > 6. Concluded that other parameters (timers etc) are set by the SP and communicated outside of the model, not requested by the customer. Need to explain this in the text. > > [Qin]: Okay. > > 7. Number of BGP sessions - SP decides and tells the customer, so this is outside the scope. Need to clarify in the text. > > [Qin]: Will check this. > > 8. Model does not cover the case of eBGP multihop between loopbacks - need to mention this in the text. > > [Qin]: I am not sure we should enumerate all the cases the model doesn’t support. It is no-ending. This model is just a base model. > > 9. Agreed no change needed > > 13. I didn't see an answer from anyone on why the BFD parameters can only be specified per access link. It seems useful to me to allow them to be specified per site too, like many other attributes. > > [Qin]: Please provide your use case. Not sure we should add this. On the other hand, if there is a real use case, it can be added through augmentation. > > 15. Connection Addressing: > > 1. I saw you added the provider address and mask to the model for the DHCP and DHCP relay cases - but if the model is only covering information requested by the customer, then this doesn't seem right. Instead, the text should explain that they are supplied by the SP and thus are outside the scope of the model. > > [Qin]: You set a pitfall for us to jump,J, but I have clarified this to you at the beginning. I would like to hear what L3SM Design Team think about this? > > 2. Addressed in the new draft - customer can request either a number of addresses or an explicit list of address ranges. > 3. Agreed no change needed > 4. I saw you added a leaf for this, but I'm not sure that's quite right. I'm not an IPv6 expert, but I thought LL addresses are always there; my question was not "LL addresses or global addresses?", it was "LL addresses only, or both LL and global addresses?". If it's LL only, then I don't think any of the other options apply - there is no need for static addresses, DHCP or SLAAC if the link only uses LL addresses. > > [Qin]:not sure one address can be both LL and global address at the same time, I would suggest to remove this parameter if this introduce confusion. > > 16. Kenichi agreed there is an issue here, but I didn't see any fix in the new draft? > > [Qin]: It is left over and will fix this. > > 17. Not sure we reached a conclusion on this one... > > [Qin]: Metric defined in this model is used for routing state calculation and path selection while access priority defines defines a preference for a particular access and decide primary/backup or loadbalancing relationship between network accesses, they serve difference purpose, don’t mix them. > > Thanks, > > > > David > > > > On 03/07/2017 10:52, Qin Wu wrote: > > Hi, All: > > The v-(02) of RFC8049bis has just been posted, > > https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ > > thanks Jan and David for valuable comments and input, the main changes include: > > 1.Specify what type of IPv6 address in the model for IPv6 connection? link-local global > > 2.Specify provider address and a list of start-end addresses from provider address > > 3.remove redundant parameters such as deny-any-except and permit-any-except under cloud-access? > > 4. Add a few text to clarify what the site is in section 6.3 > > 5. Add a few text to clarify why having customer-name. > > 6. Fixed two typos pointed by Jan recently. > > > > Talking with L3Sm design team, we believe how information is communicated by SP to the customer is beyond the scope of > > RFC8049 has already been clarified in section 6.6, 2nd paragraph, section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.12.2.2,4th paragraph. > > > > Regarding whether AS number under BGP protocol is supposed to be the customer's AS number or the SP's AS number, we think AS number as > > part of BGP protocol related parameters are applied to provider to customer boundary, therefore the answer is depending on > > how the management model is administered. > > > > As Jan pointed out, we still have some new mandatory fields introduced in v-(02) haven’t been reflected in the examples. But he is okay with the current shape. > > Please review these changes, let us know if there is any additional comments. > > > > Regards! > > Qin (on behalf of team) > > > > > > > > > > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm > > > > > > -- > David Ball > > > -- David Ball From nobody Thu Jul 13 03:54:43 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EEC124E15 for ; Thu, 13 Jul 2017 03:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 7cUoiRocBK_i for ; Thu, 13 Jul 2017 03:54:39 -0700 (PDT) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id CCE5F1242F7 for ; Thu, 13 Jul 2017 03:54:38 -0700 (PDT) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 0A9E0E0056; Thu, 13 Jul 2017 19:54:38 +0900 (JST) Received: from LTMC2146.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Thu, 13 Jul 2017 19:54:37 +0900 Received: from LTMC2146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id D90BF30007F; Thu, 13 Jul 2017 19:54:37 +0900 (JST) Received: from LTMC2151.kddi.com (post-incheck [10.206.0.239]) by LTMC2146.kddi.com (Postfix) with ESMTP id CE7A630007E; Thu, 13 Jul 2017 19:54:37 +0900 (JST) Received: from LTMC2151.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v6DAsbCx024696; Thu, 13 Jul 2017 19:54:37 +0900 Received: from LTMC2151.kddi.com.mid_23671512 (localhost.localdomain [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id v6DAiZsb015574; Thu, 13 Jul 2017 19:44:35 +0900 X-SA-MID: 23671512 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Thu, 13 Jul 2017 19:44:34 +0900 From: "Ogaki, Kenichi" To: "'David Ball'" , "'Qin Wu'" , Cc: "'Benoit Claise \(bclaise\)'" , References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> <000301d2faeb$22864890$6792d9b0$@kddi.com> <42e2c5d8-05fa-65f2-52e4-ec2db62b0a6f@cisco.com> In-Reply-To: <42e2c5d8-05fa-65f2-52e4-ec2db62b0a6f@cisco.com> Date: Thu, 13 Jul 2017 19:44:34 +0900 Message-ID: <00e601d2fbc5$04470ce0$0cd526a0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt7Pfdo0zsTznSH6gPl8UfrToyiwF/DcMJAdAfHcMBM/6/AAFtjpOvAswpt5Gi1cWRYA== Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 10:54:43 -0000 Hi David, See comments inline [KO], please. All the best, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball Sent: Wednesday, July 12, 2017 6:33 PM To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org Cc: 'Benoit Claise (bclaise)'; adrian@olddog.co.uk Subject: Re: [L3sm] Followup of RFC8049bis Hi Kenichi, On 12/07/2017 09:44, Ogaki, Kenichi wrote: > Hi David, > >> * All information that needs to be exchanged between the SP and the = Customer? >> * Only information requested by the customer to the SP? >> * Something else? If so, what? > I believe your second one is closer to the rational of this whole = model, but the customer requests not information, but vpn service = provisioning. Yes agreed, that is a better way of putting it. The model contains = information that needs to be included in a customer's request to a SP = for VPN service provisioning. > Also, the SP needs all information required to provision the vpn = service, when a customer requests a vpn service. > In that sense, we may be able to understand your first one also = implies this. Here I don't quite agree - the first one would also include information = that the SP needs to give the customer in order for them to be able to = use the service. If I understand correctly, that is not intended to be = included in the yang model, right? [KO] I can understand. > Anyway, does the following paragraph in section 5 cover the rational? > > The idea of the L3 IP VPN service model is to propose an abstracted > interface between customers and network operators to manage > configuration of components of an L3VPN service. A typical = scenario > would be to use this model as an input for an orchestration layer > that will be responsible for translating it to an orchestrated > configuration of network elements that will be part of the = service. To me, this paragraph does not clearly express that the information that = needs to be passed from the SP to the customer is not in scope. I would = like to see that stated explicitly, if that is indeed the intent. [KO] I can't agree with that. Even though the current model doesn't intend something, to exclude their = future possibility only brings a disadvantage rather than an advantage. I can't see any major advantage to state that explicitly. Honestly, I proposed to support a notification mechanism to pass some = information from SP to customer earlier. This is a future possibility. https://www.ietf.org/mail-archive/web/l3sm/current/msg00284.html Thanks, David > > I think Qin's example is a complementary but a necessary procedure to = utilize this model. > > All the best, > Kenichi > > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Tuesday, July 11, 2017 8:10 PM > To: Qin Wu; l3sm@ietf.org > Cc: Benoit Claise (bclaise); adrian@olddog.co.uk > Subject: Re: [L3sm] Followup of RFC8049bis > > Hi Qin, > > I'm now really confused again about issue 1. You point to text in = section 6 that concerns a small number of specific leaves in the model; = but my question is about the scope of the model as a whole. In an = answer to another issue, you said: "In Theory, both customer and = provider can use this model parameter to talk to each other." - that = seems to contradict Kenichi's answer to my original question. > > In essence, my question is about the scope of the model as a whole. = Is the model intended to include: > > * All information that needs to be exchanged between the SP and the = Customer? > * Only information requested by the customer to the SP? > * Something else? If so, what? > > I think this may be the source of confusion for a number of the other = issues so I'll hold off on responding about those until we've addressed = this. I don't have a strong opinion on the answer but I would really = like the scope of the model to be clearly stated so that we can check = the rest of the content against the scope. Currently it seems to be = closest to the second one (and that was what I said in my original email = and what Kenichi confirmed), but your reply seems to suggest something = different. > > > > > > David > > > > > On 10/07/2017 14:47, Qin Wu wrote: > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: David Ball [mailto:daviball@cisco.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2017=E5=B9=B47=E6=9C=885=E6=97=A5 19:47 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu; l3sm@ietf.org; l2sm@ietf.org > =E6=8A=84=E9=80=81: Benoit Claise (bclaise); adrian@olddog.co.uk > =E4=B8=BB=E9=A2=98: Re: [L3sm] Followup of RFC8049bis > > =09 > > Thanks Qin. > > I thought it might be useful to summarize the discussion on each of = my original questions so far. In general, I imagine that if I had a = question, other readers might have the same question too, so even if we = have answered the question on the thread, I think it is good to provide = the clarification in the text as well. > > 1. You mention below that you think this is already described in = section 6.6 and 6.12. However, the fact that the model only covers = information requested by the customer to the SP is a key aspect of the = model that is critical to the reader's understanding, so I think it = needs to be explained much more clearly, and much earlier in the = document i.e. in section 5. > > [Qin]: You need to read carefully, it clearly explain what kind = of information responded by SP to the Customer is not in the scope of = this document. For most of other information, it doesn=E2=80=99t require = SP to respond back to Customer. > > See section 6.6 , 3rd paragraph: > > =E2=80=9CIf a constraint is too strict and cannot be fulfilled, the = management system MUST NOT provision the site and SHOULD provide = relevant information to the user.=E2=80=9D > > See section 6.6.3 2nd paragraph ,1st bullet: > > =E2=80=9CIf the "strict" leaf is equal to "false"(default) and if the = requested media type cannot be fulfilled, the management system can = select another media type. The supported media types SHOULD be = communicated by the SP to the customer via a mechanism that is out of = scope for this document.=E2=80=9D > > See section 6.12.2.2,4th paragraph: > > =E2=80=9Csome constraints may not be completely fulfilled by the SP; = in this case, the SP should advise the customer about the limitations. = How this communication is done is out of scope for this = document.=E2=80=9D > > 2. As far as I saw, you only added one sentence about this - I think = a bit more is needed! In fact I wonder if we are even all on the same = page in the emails, since your answer didn't seem to quite align with = what Kenichi and Stephane said. > > [Qin]: Site notion has been well clarified in the document: > > =E2=80=9C A site has several characteristics: > > =09 > > o Unique identifier (site-id): uniquely identifies the site=20 > within > > the overall network infrastructure. The identifier is a string > > that allows any encoding for the local administration of the=20 > VPN > > service. > > =09 > > o Locations (locations): site location information that allows=20 > easy > > retrieval of information from the nearest available resources. = > A > > site may be composed of multiple locations. > > =09 > > o Devices (devices): allows the customer to request one or more > > customer premises equipment entities from the SP for a=20 > particular > > site. > > =09 > > o Management (management): defines the type of management for the > > site -- for example, co-managed, customer-managed, or provider- > > managed. See Section 6.10 = . > > =09 > > o Site network accesses (site-network-accesses): defines the list = > of > > network accesses associated with the sites, and their=20 > properties > > -- especially bearer, connection, and service parameters. > > =E2=80=9D > > I add one sentence to get consist with this. The proposed changes = have got approved by Stepane and Kenichi already before posting to the = list. > > 3. I didn't see any text added to address this - and again, I'm not = sure we're all on the same page yet. Kenichi agreed that there is no = technical difference between using SubVPN and using multiple sites, = although obviously this is related to question 2. At the very least, = the ambiguity in the existing text should be fixed! > > [Qin]:I think the key difference between subVPN and multi-VPN is=20 > whether they share the same bearer. It is clarified in the section=20 > 6.5.1.3 > > =E2=80=9C > > It is similar to having separate sites, but in this case the customer > > wants to share some physical components while maintaining strong = communication isolation between the affiliates. > > =E2=80=9D > > Physical components are referred to the bearer. > > I think this is sufficient. If you think we should further limit = subVPN to the same bearer and same CPE, please let me know. > > 4. Addressed in the new draft > 5. Conclusion is that using a single VPN service for multiple clouds = is technically the same as using a separate VPN service for each cloud, = but it might be easier operationally. This needs to be explained in the = draft. > > [Qin]: I believe using a separate VPN service for each cloud is not = in the scope of this document. This draft clear explained to support = public cloud access, support private cloud access with a single VPN = service. > > 6. Addressed in the new draft > 7. Can be addressed with an augment, so no change needed > > [Qin]: Agree, do you think section 6.1 =E2=80=9CFeatures and = Augmentation=E2=80=9D is sufficient to address your comment with any = text change. > > 8. You agreed to add some additional explanation about MTU, but I = didn't see any changes in the draft? > > [Qin]:Addressed in the previous version which address Jan=E2=80=99s = comments,=20 > See > > =E2=80=9C > > leaf svc-mtu { > > type uint16; > > units bytes; > > mandatory true; > > description > > "MTU at service level. If the service is IP, > > it refers to the IP MTU. If CsC is enabled, > > the requested 'svc-mtu' leaf will refer to the > > MPLS MTU and not to the IP MTU. "; > > =E2=80=9D > > 9. Conclusion was that max routes per VPN might be useful but hard to = implement, so no change needed. > 10. Per-VPN QoS policy can be achieved in most cases using the = target-sites option - need to add text to explain this > > [Qin]: Okay. > > 11. Can specify different performance objectives by using more = classes, no change needed > 12. I still don't understand what the SP is supposed to do in a = multipoint case where end-to-end is true. Actually, even in a P2P case, = there is a problem if the guaranteed end-to-end bandwidth is specified = differently at each end. Should the SP take the higher or lower value? > > [Qin]: I think this depends on the SP's implementation of the = service. > > 13. Routing: > > 1. Agreed no change needed > 2. Agreed no change needed > 3. Concluded that other parameters (timers etc) are set by the SP = and communicated outside of the model, not requested by the customer. = Need to explain this in the text. > > [Qin]: Okay. > > 4. Addressed in the new draft > 5. I did not understand your comment about the BGP AS number below - = all the attributes in the model are applied at the customer to SP = boundary, but it still needs to be clarified whether it is the = customer's or SP's AS number. Actually given that the model is only = covering what the customer requests, I guess it would always be the = customer's AS number (since the customer wouldn't need to request the = SP's AS number, that would be provided by the SP to the customer, which = is outside the scope of the model). So I think the text should clarify = that this is the customer's AS number. > > [Qin] Not sure we should distinct the parameter used = by customer to talk to provider from the parameter used by provider to = talk to customer. In Theory, both customer and provider can use this = model parameter to talk to each other. I would like to hear = other=E2=80=99s opinion. > > 6. Concluded that other parameters (timers etc) are set by the SP = and communicated outside of the model, not requested by the customer. = Need to explain this in the text. > > [Qin]: Okay. > > 7. Number of BGP sessions - SP decides and tells the customer, so = this is outside the scope. Need to clarify in the text. > > [Qin]: Will check this. > > 8. Model does not cover the case of eBGP multihop between loopbacks = - need to mention this in the text. > > [Qin]: I am not sure we should enumerate all the cases the = model doesn=E2=80=99t support. It is no-ending. This model is just a = base model. > > 9. Agreed no change needed > > 13. I didn't see an answer from anyone on why the BFD parameters can = only be specified per access link. It seems useful to me to allow them = to be specified per site too, like many other attributes. > > [Qin]: Please provide your use case. Not sure we should add this. On = the other hand, if there is a real use case, it can be added through = augmentation. > > 15. Connection Addressing: > > 1. I saw you added the provider address and mask to the model for = the DHCP and DHCP relay cases - but if the model is only covering = information requested by the customer, then this doesn't seem right. = Instead, the text should explain that they are supplied by the SP and = thus are outside the scope of the model. > > [Qin]: You set a pitfall for us to jump,J, but I have = clarified this to you at the beginning. I would like to hear what L3SM = Design Team think about this? > > 2. Addressed in the new draft - customer can request either a number = of addresses or an explicit list of address ranges. > 3. Agreed no change needed > 4. I saw you added a leaf for this, but I'm not sure that's quite = right. I'm not an IPv6 expert, but I thought LL addresses are always = there; my question was not "LL addresses or global addresses?", it was = "LL addresses only, or both LL and global addresses?". If it's LL only, = then I don't think any of the other options apply - there is no need for = static addresses, DHCP or SLAAC if the link only uses LL addresses. > > [Qin]:not sure one address can be both LL and global address = at the same time, I would suggest to remove this parameter if this = introduce confusion. > > 16. Kenichi agreed there is an issue here, but I didn't see any fix = in the new draft? > > [Qin]: It is left over and will fix this. > > 17. Not sure we reached a conclusion on this one... > > [Qin]: Metric defined in this model is used for routing state = calculation and path selection while access priority defines defines a = preference for a particular access and decide primary/backup or = loadbalancing relationship between network accesses, they serve = difference purpose, don=E2=80=99t mix them. > > Thanks, > > =09 > > David > > =09 > > On 03/07/2017 10:52, Qin Wu wrote: > > Hi, All: > > The v-(02) of RFC8049bis has just been posted, > > https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ > > thanks Jan and David for valuable comments and input, the main = changes include: > > 1.Specify what type of IPv6 address in the model for IPv6=20 > connection? link-local global > > 2.Specify provider address and a list of start-end addresses from=20 > provider address > > 3.remove redundant parameters such as deny-any-except and = permit-any-except under cloud-access? > > 4. Add a few text to clarify what the site is in section 6.3 > > 5. Add a few text to clarify why having customer-name. > > 6. Fixed two typos pointed by Jan recently. > > =09 > > Talking with L3Sm design team, we believe how information is=20 > communicated by SP to the customer is beyond the scope of > > RFC8049 has already been clarified in section 6.6, 2nd paragraph, = section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section = 6.12.2.2,4th paragraph. > > =09 > > Regarding whether AS number under BGP protocol is supposed to be the = > customer's AS number or the SP's AS number, we think AS number as > > part of BGP protocol related parameters are applied to provider to=20 > customer boundary, therefore the answer is depending on > > how the management model is administered. > > =09 > > As Jan pointed out, we still have some new mandatory fields = introduced in v-(02) haven=E2=80=99t been reflected in the examples. But = he is okay with the current shape. > > Please review these changes, let us know if there is any additional = comments. > > =09 > > Regards! > > Qin (on behalf of team) > > =09 > > =09 > > =09 > =09 > =09 > =09 > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm > > =09 > =09 > =09 > > -- > David Ball > > > -- David Ball _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Thu Jul 13 04:30:05 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1B512EC15 for ; Thu, 13 Jul 2017 04:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 fgWbOwIbXixX for ; Thu, 13 Jul 2017 04:30:02 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F03112EAFF for ; Thu, 13 Jul 2017 04:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4748; q=dns/txt; s=iport; t=1499945401; x=1501155001; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=TrMflxz3J8EhMkitUYD28qIuh7kgVRvcvU+2jWu0JZg=; b=VMEYRkRMIBPi2XjGvm2d+66oVsqqqsEwGbu9Qa+BYrU9UPltPjwoFpS1 AQjjL80rqDxh6B0g/XLI09XZlno5mUWAakTFs5MWN61FRIkasXSXPwVKc SQMN5CcrY+Dytcz0ui0j56GEfOJbbZePZupM363zZXqD3NGFtgqX3t8cz A=; X-IronPort-AV: E=Sophos;i="5.40,353,1496102400"; d="scan'208,217";a="653217027" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2017 11:29:59 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6DBTroU009135; Thu, 13 Jul 2017 11:29:54 GMT To: "Ogaki, Kenichi" , "'Qin Wu'" , l3sm@ietf.org Cc: "'Benoit Claise (bclaise)'" , adrian@olddog.co.uk References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> <000301d2faeb$22864890$6792d9b0$@kddi.com> <42e2c5d8-05fa-65f2-52e4-ec2db62b0a6f@cisco.com> <00e601d2fbc5$04470ce0$0cd526a0$@kddi.com> From: David Ball Message-ID: Date: Thu, 13 Jul 2017 12:29:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <00e601d2fbc5$04470ce0$0cd526a0$@kddi.com> Content-Type: multipart/alternative; boundary="------------410D9C476592B0A028F6253E" Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 11:30:04 -0000 This is a multi-part message in MIME format. --------------410D9C476592B0A028F6253E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Kenichi, On 13/07/2017 11:44, Ogaki, Kenichi wrote: >> Anyway, does the following paragraph in section 5 cover the rational? >> >> The idea of the L3 IP VPN service model is to propose an abstracted >> interface between customers and network operators to manage >> configuration of components of an L3VPN service. A typical scenario >> would be to use this model as an input for an orchestration layer >> that will be responsible for translating it to an orchestrated >> configuration of network elements that will be part of the service. > To me, this paragraph does not clearly express that the information that needs to be passed from the SP to the customer is not in scope. I would like to see that stated explicitly, if that is indeed the intent. > > [KO] I can't agree with that. > Even though the current model doesn't intend something, to exclude their future possibility only brings a disadvantage rather than an advantage. > I can't see any major advantage to state that explicitly. I agree, we do not want to preclude future enhancements. However, I do think this is critical to help an unfamiliar reader understand and use the model we have today. How about text like this: "The version of the model described in this document does not include information that is passed from the SP to the customer. This could be added in a future extension or augmentation." Another way of looking at it: would it be correct to say that the way the model is intended to be used is that the SP's system is the server and the customer's system is the client? In that case, any information intended to be passed from the SP to the customer could be modelled with "config false", meaning that the SP could change it but the customer could not. David -- David Ball --------------410D9C476592B0A028F6253E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Kenichi,

On 13/07/2017 11:44, Ogaki, Kenichi wrote:
Anyway, does the following paragraph in section 5 cover the rational?

The idea of the L3 IP VPN service model is to propose an abstracted
    interface between customers and network operators to manage
    configuration of components of an L3VPN service.  A typical scenario
    would be to use this model as an input for an orchestration layer
    that will be responsible for translating it to an orchestrated
    configuration of network elements that will be part of the service.

To me, this paragraph does not clearly express that the information that needs to be passed from the SP to the customer is not in scope.  I would like to see that stated explicitly, if that is indeed the intent.

[KO] I can't agree with that.
Even though the current model doesn't intend something, to exclude their future possibility only brings a disadvantage rather than an advantage.
I can't see any major advantage to state that explicitly.
I agree, we do not want to preclude future enhancements.  However, I do think this is critical to help an unfamiliar reader understand and use the model we have today.  How about text like this:

"The version of the model described in this document does not include information that is passed from the SP to the customer.  This could be added in a future extension or augmentation."

Another way of looking at it: would it be correct to say that the way the model is intended to be used is that the SP's system is the server and the customer's system is the client?  In that case, any information intended to be passed from the SP to the customer could be modelled with "config false", meaning that the SP could change it but the customer could not.


    David

-- 
David Ball
<daviball@cisco.com>
--------------410D9C476592B0A028F6253E-- From nobody Fri Jul 14 01:15:38 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1278126B6D for ; Fri, 14 Jul 2017 01:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 nscqqVafwUDw for ; Fri, 14 Jul 2017 01:15:35 -0700 (PDT) Received: from post-send.kddi.com (athena2.kddi.com [27.90.165.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3001E1200C1 for ; Fri, 14 Jul 2017 01:15:34 -0700 (PDT) Received: from LTMC2121.kddi.com (LTMC2121.kddi.com [10.206.0.61]) by post-send.kddi.com (KDDI Mail) with ESMTP id E39F4E0055; Fri, 14 Jul 2017 17:15:33 +0900 (JST) Received: from LTMC2146.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2121.kddi.com with ESMTP; Fri, 14 Jul 2017 17:15:33 +0900 Received: from LTMC2146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id B137530005D; Fri, 14 Jul 2017 17:15:33 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2146.kddi.com (Postfix) with ESMTP id A5EC0300051; Fri, 14 Jul 2017 17:15:33 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v6E8FXwO017555; Fri, 14 Jul 2017 17:15:33 +0900 Received: from LTMC2152.kddi.com.mid_23547935 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v6E85SJI002720; Fri, 14 Jul 2017 17:05:28 +0900 X-SA-MID: 23547935 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Fri, 14 Jul 2017 17:05:28 +0900 From: "Ogaki, Kenichi" To: "'David Ball'" , "'Qin Wu'" , Cc: "'Benoit Claise \(bclaise\)'" , References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> <000301d2faeb$22864890$6792d9b0$@kddi.com> <42e2c5d8-05fa-65f2-52e4-ec2db62b0a6f@cisco.com> <00e601d2fbc5$04470ce0$0cd526a0$@kddi.com> In-Reply-To: Date: Fri, 14 Jul 2017 17:05:28 +0900 Message-ID: <00a001d2fc77$f4a53060$ddef9120$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt7Pfdo0zsTznSH6gPl8UfrToyiwF/DcMJAdAfHcMBM/6/AAFtjpOvAswpt5EBwG0YnwFr5HoFor2eJCA= Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 08:15:37 -0000 Hi David, >Another way of looking at it: would it be correct to say that the way the model is intended to be used is that the SP's system is the server and the customer's >system is the client? [KO] This best describes the rational of this model. >In that case, any information intended to be passed from the SP to the customer could be modelled with "config false", meaning that the >SP could change it but the customer could not. [KO] Yes, "config false" or NACM is utilized for this purpose. Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball Sent: Thursday, July 13, 2017 8:30 PM To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org Cc: 'Benoit Claise (bclaise)'; adrian@olddog.co.uk Subject: Re: [L3sm] Followup of RFC8049bis Hi Kenichi, On 13/07/2017 11:44, Ogaki, Kenichi wrote: Anyway, does the following paragraph in section 5 cover the rational? The idea of the L3 IP VPN service model is to propose an abstracted interface between customers and network operators to manage configuration of components of an L3VPN service. A typical scenario would be to use this model as an input for an orchestration layer that will be responsible for translating it to an orchestrated configuration of network elements that will be part of the service. To me, this paragraph does not clearly express that the information that needs to be passed from the SP to the customer is not in scope. I would like to see that stated explicitly, if that is indeed the intent. [KO] I can't agree with that. Even though the current model doesn't intend something, to exclude their future possibility only brings a disadvantage rather than an advantage. I can't see any major advantage to state that explicitly. I agree, we do not want to preclude future enhancements. However, I do think this is critical to help an unfamiliar reader understand and use the model we have today. How about text like this: "The version of the model described in this document does not include information that is passed from the SP to the customer. This could be added in a future extension or augmentation." Another way of looking at it: would it be correct to say that the way the model is intended to be used is that the SP's system is the server and the customer's system is the client? In that case, any information intended to be passed from the SP to the customer could be modelled with "config false", meaning that the SP could change it but the customer could not. David -- David Ball From nobody Tue Jul 18 04:56:20 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE93131DFE for ; Tue, 18 Jul 2017 04:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 XOghMM0HNtCq for ; Tue, 18 Jul 2017 04:56:17 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C7B131897 for ; Tue, 18 Jul 2017 04:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2878; q=dns/txt; s=iport; t=1500378977; x=1501588577; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=AQit16qon0sMoLwb92g3uI0INJkXe0uuLIbSVbCG4kw=; b=OK+LlIekDX1Di+wzNPuUjGqnicMfOwGVsyLZtaptb//CDlfbyrxuQ2SX ob3QjDQ6RntlJzPsFfwAW8EPtQ/wp6DBvXVmpOkDdZ4phyK+jM5evY91Q o8PbX6f4625i0lnatsq84edimvDjH+7D4l5UvtGJBxiSGxS/cLoUpPYdh g=; X-IronPort-AV: E=Sophos;i="5.40,377,1496102400"; d="scan'208";a="653322407" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2017 11:56:15 +0000 Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6IBuF50010034; Tue, 18 Jul 2017 11:56:15 GMT To: "Ogaki, Kenichi" , "'Qin Wu'" , l3sm@ietf.org Cc: "'Benoit Claise (bclaise)'" , adrian@olddog.co.uk References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> <000301d2faeb$22864890$6792d9b0$@kddi.com> <42e2c5d8-05fa-65f2-52e4-ec2db62b0a6f@cisco.com> <00e601d2fbc5$04470ce0$0cd526a0$@kddi.com> <00a001d2fc77$f4a53060$ddef9120$@kddi.com> From: David Ball Message-ID: Date: Tue, 18 Jul 2017 12:56:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <00a001d2fc77$f4a53060$ddef9120$@kddi.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:56:19 -0000 Qin, do you agree here? Could we put some statement like this in section 5? David On 14/07/2017 09:05, Ogaki, Kenichi wrote: > Hi David, > >> Another way of looking at it: would it be correct to say that the way the model is intended to be used is that the SP's system is the server and the customer's >> system is the client? > [KO] This best describes the rational of this model. > >> In that case, any information intended to be passed from the SP to the customer could be modelled with "config false", meaning that the >> SP could change it but the customer could not. > [KO] Yes, "config false" or NACM is utilized for this purpose. > > Thanks, > Kenichi > > -----Original Message----- > From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of David Ball > Sent: Thursday, July 13, 2017 8:30 PM > To: Ogaki, Kenichi; 'Qin Wu'; l3sm@ietf.org > Cc: 'Benoit Claise (bclaise)'; adrian@olddog.co.uk > Subject: Re: [L3sm] Followup of RFC8049bis > > Hi Kenichi, > > > On 13/07/2017 11:44, Ogaki, Kenichi wrote: > > > Anyway, does the following paragraph in section 5 cover the rational? > > The idea of the L3 IP VPN service model is to propose an abstracted > interface between customers and network operators to manage > configuration of components of an L3VPN service. A typical scenario > would be to use this model as an input for an orchestration layer > that will be responsible for translating it to an orchestrated > configuration of network elements that will be part of the service. > > To me, this paragraph does not clearly express that the information that needs to be passed from the SP to the customer is not in scope. I would like to see that stated explicitly, if that is indeed the intent. > > [KO] I can't agree with that. > Even though the current model doesn't intend something, to exclude their future possibility only brings a disadvantage rather than an advantage. > I can't see any major advantage to state that explicitly. > > I agree, we do not want to preclude future enhancements. However, I do think this is critical to help an unfamiliar reader understand and use the model we have today. How about text like this: > > "The version of the model described in this document does not include information that is passed from the SP to the customer. This could be added in a future extension or augmentation." > > Another way of looking at it: would it be correct to say that the way the model is intended to be used is that the SP's system is the server and the customer's system is the client? In that case, any information intended to be passed from the SP to the customer could be modelled with "config false", meaning that the SP could change it but the customer could not. > > > David > > -- David Ball From nobody Thu Jul 20 08:36:43 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43E812EC46 for ; Thu, 20 Jul 2017 08:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 M1wkuW6PY5Ey for ; Thu, 20 Jul 2017 08:36:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7E61252BA for ; Thu, 20 Jul 2017 08:36:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRQ61258; Thu, 20 Jul 2017 15:36:38 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Jul 2017 16:36:37 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.9]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 20 Jul 2017 23:36:33 +0800 From: Qin Wu To: David Ball , "Ogaki, Kenichi" , "l3sm@ietf.org" CC: "'Benoit Claise (bclaise)'" , "adrian@olddog.co.uk" Thread-Topic: [L3sm] Followup of RFC8049bis Thread-Index: AdLz4gQczWlV+rrbRBePS8Ez8xfWvQBX1HKAAQwkggAAIE/cAAAtOxkAAAGv/IAANMiFAAABlSqAACsm+gAA0TnHgAB9Aari Date: Thu, 20 Jul 2017 15:36:33 +0000 Message-ID: References: <98205783-7f3c-bcf7-fecb-e755add6eb25@cisco.com> <4b5d80e8-147a-50b7-f78f-2eef9de6c231@cisco.com> <000301d2faeb$22864890$6792d9b0$@kddi.com> <42e2c5d8-05fa-65f2-52e4-ec2db62b0a6f@cisco.com> <00e601d2fbc5$04470ce0$0cd526a0$@kddi.com> <00a001d2fc77$f4a53060$ddef9120$@kddi.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.72.133] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5970CE06.020F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 669fe98d0a128425993887b2b2a47511 Archived-At: Subject: Re: [L3sm] Followup of RFC8049bis X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:36:42 -0000 SW4gdHJpcCwgd2lsbCBwaW5nIGFsbCBvdGhlciBMMlNNIGRlc2lnbiB0ZWFtIG1lbWJlcnMgZm9y IHRoaXMsIGFuZCBnZXQgYmFjayB0byB5b3UuDQoNCi1RaW4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCreivP7IyzogRGF2aWQgQmFsbCBbZGF2aWJhbGxAY2lzY28u Y29tXQ0Kt6LLzcqxvOQ6IDIwMTfE6jfUwjE4yNUgMTk6NTYNCsrVvP7IyzogT2dha2ksIEtlbmlj aGk7IFFpbiBXdTsgbDNzbUBpZXRmLm9yZw0Ks63LzTogJ0Jlbm9pdCBDbGFpc2UgKGJjbGFpc2Up JzsgYWRyaWFuQG9sZGRvZy5jby51aw0K1vfM4jogUmU6IFtMM3NtXSBGb2xsb3d1cCBvZiBSRkM4 MDQ5YmlzDQoNClFpbiwgZG8geW91IGFncmVlIGhlcmU/ICBDb3VsZCB3ZSBwdXQgc29tZSBzdGF0 ZW1lbnQgbGlrZSB0aGlzIGluIHNlY3Rpb24gNT8NCg0KICAgICBEYXZpZA0KDQpPbiAxNC8wNy8y MDE3IDA5OjA1LCBPZ2FraSwgS2VuaWNoaSB3cm90ZToNCj4gSGkgRGF2aWQsDQo+DQo+PiBBbm90 aGVyIHdheSBvZiBsb29raW5nIGF0IGl0OiB3b3VsZCBpdCBiZSBjb3JyZWN0IHRvIHNheSB0aGF0 IHRoZSB3YXkgdGhlIG1vZGVsIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgaXMgdGhhdCB0aGUgU1An cyBzeXN0ZW0gaXMgdGhlIHNlcnZlciBhbmQgdGhlIGN1c3RvbWVyJ3MNCj4+IHN5c3RlbSBpcyB0 aGUgY2xpZW50Pw0KPiBbS09dIFRoaXMgYmVzdCBkZXNjcmliZXMgdGhlIHJhdGlvbmFsIG9mIHRo aXMgbW9kZWwuDQo+DQo+PiBJbiB0aGF0IGNhc2UsIGFueSBpbmZvcm1hdGlvbiBpbnRlbmRlZCB0 byBiZSBwYXNzZWQgZnJvbSB0aGUgU1AgdG8gdGhlIGN1c3RvbWVyIGNvdWxkIGJlIG1vZGVsbGVk IHdpdGggImNvbmZpZyBmYWxzZSIsIG1lYW5pbmcgdGhhdCB0aGUNCj4+IFNQIGNvdWxkIGNoYW5n ZSBpdCBidXQgdGhlIGN1c3RvbWVyIGNvdWxkIG5vdC4NCj4gW0tPXSBZZXMsICJjb25maWcgZmFs c2UiIG9yIE5BQ00gaXMgdXRpbGl6ZWQgZm9yIHRoaXMgcHVycG9zZS4NCj4NCj4gVGhhbmtzLA0K PiBLZW5pY2hpDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEwzc20g W21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBCYWxsDQo+ IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEzLCAyMDE3IDg6MzAgUE0NCj4gVG86IE9nYWtpLCBLZW5p Y2hpOyAnUWluIFd1JzsgbDNzbUBpZXRmLm9yZw0KPiBDYzogJ0Jlbm9pdCBDbGFpc2UgKGJjbGFp c2UpJzsgYWRyaWFuQG9sZGRvZy5jby51aw0KPiBTdWJqZWN0OiBSZTogW0wzc21dIEZvbGxvd3Vw IG9mIFJGQzgwNDliaXMNCj4NCj4gSGkgS2VuaWNoaSwNCj4NCj4NCj4gT24gMTMvMDcvMjAxNyAx MTo0NCwgT2dha2ksIEtlbmljaGkgd3JvdGU6DQo+DQo+DQo+ICAgICAgICAgICAgICAgQW55d2F5 LCBkb2VzIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIGluIHNlY3Rpb24gNSBjb3ZlciB0aGUgcmF0 aW9uYWw/DQo+DQo+ICAgICAgICAgICAgICAgVGhlIGlkZWEgb2YgdGhlIEwzIElQIFZQTiBzZXJ2 aWNlIG1vZGVsIGlzIHRvIHByb3Bvc2UgYW4gYWJzdHJhY3RlZA0KPiAgICAgICAgICAgICAgICAg ICBpbnRlcmZhY2UgYmV0d2VlbiBjdXN0b21lcnMgYW5kIG5ldHdvcmsgb3BlcmF0b3JzIHRvIG1h bmFnZQ0KPiAgICAgICAgICAgICAgICAgICBjb25maWd1cmF0aW9uIG9mIGNvbXBvbmVudHMgb2Yg YW4gTDNWUE4gc2VydmljZS4gIEEgdHlwaWNhbCBzY2VuYXJpbw0KPiAgICAgICAgICAgICAgICAg ICB3b3VsZCBiZSB0byB1c2UgdGhpcyBtb2RlbCBhcyBhbiBpbnB1dCBmb3IgYW4gb3JjaGVzdHJh dGlvbiBsYXllcg0KPiAgICAgICAgICAgICAgICAgICB0aGF0IHdpbGwgYmUgcmVzcG9uc2libGUg Zm9yIHRyYW5zbGF0aW5nIGl0IHRvIGFuIG9yY2hlc3RyYXRlZA0KPiAgICAgICAgICAgICAgICAg ICBjb25maWd1cmF0aW9uIG9mIG5ldHdvcmsgZWxlbWVudHMgdGhhdCB3aWxsIGJlIHBhcnQgb2Yg dGhlIHNlcnZpY2UuDQo+DQo+ICAgICAgIFRvIG1lLCB0aGlzIHBhcmFncmFwaCBkb2VzIG5vdCBj bGVhcmx5IGV4cHJlc3MgdGhhdCB0aGUgaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBwYXNz ZWQgZnJvbSB0aGUgU1AgdG8gdGhlIGN1c3RvbWVyIGlzIG5vdCBpbiBzY29wZS4gIEkgd291bGQg bGlrZSB0byBzZWUgdGhhdCBzdGF0ZWQgZXhwbGljaXRseSwgaWYgdGhhdCBpcyBpbmRlZWQgdGhl IGludGVudC4NCj4NCj4gICAgICAgW0tPXSBJIGNhbid0IGFncmVlIHdpdGggdGhhdC4NCj4gICAg ICAgRXZlbiB0aG91Z2ggdGhlIGN1cnJlbnQgbW9kZWwgZG9lc24ndCBpbnRlbmQgc29tZXRoaW5n LCB0byBleGNsdWRlIHRoZWlyIGZ1dHVyZSBwb3NzaWJpbGl0eSBvbmx5IGJyaW5ncyBhIGRpc2Fk dmFudGFnZSByYXRoZXIgdGhhbiBhbiBhZHZhbnRhZ2UuDQo+ICAgICAgIEkgY2FuJ3Qgc2VlIGFu eSBtYWpvciBhZHZhbnRhZ2UgdG8gc3RhdGUgdGhhdCBleHBsaWNpdGx5Lg0KPg0KPiBJIGFncmVl LCB3ZSBkbyBub3Qgd2FudCB0byBwcmVjbHVkZSBmdXR1cmUgZW5oYW5jZW1lbnRzLiAgSG93ZXZl ciwgSSBkbyB0aGluayB0aGlzIGlzIGNyaXRpY2FsIHRvIGhlbHAgYW4gdW5mYW1pbGlhciByZWFk ZXIgdW5kZXJzdGFuZCBhbmQgdXNlIHRoZSBtb2RlbCB3ZSBoYXZlIHRvZGF5LiAgSG93IGFib3V0 IHRleHQgbGlrZSB0aGlzOg0KPg0KPiAiVGhlIHZlcnNpb24gb2YgdGhlIG1vZGVsIGRlc2NyaWJl ZCBpbiB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGluY2x1ZGUgaW5mb3JtYXRpb24gdGhhdCBpcyBw YXNzZWQgZnJvbSB0aGUgU1AgdG8gdGhlIGN1c3RvbWVyLiAgVGhpcyBjb3VsZCBiZSBhZGRlZCBp biBhIGZ1dHVyZSBleHRlbnNpb24gb3IgYXVnbWVudGF0aW9uLiINCj4NCj4gQW5vdGhlciB3YXkg b2YgbG9va2luZyBhdCBpdDogd291bGQgaXQgYmUgY29ycmVjdCB0byBzYXkgdGhhdCB0aGUgd2F5 IHRoZSBtb2RlbCBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIGlzIHRoYXQgdGhlIFNQJ3Mgc3lzdGVt IGlzIHRoZSBzZXJ2ZXIgYW5kIHRoZSBjdXN0b21lcidzIHN5c3RlbSBpcyB0aGUgY2xpZW50PyAg SW4gdGhhdCBjYXNlLCBhbnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgdG8gYmUgcGFzc2VkIGZyb20g dGhlIFNQIHRvIHRoZSBjdXN0b21lciBjb3VsZCBiZSBtb2RlbGxlZCB3aXRoICJjb25maWcgZmFs c2UiLCBtZWFuaW5nIHRoYXQgdGhlIFNQIGNvdWxkIGNoYW5nZSBpdCBidXQgdGhlIGN1c3RvbWVy IGNvdWxkIG5vdC4NCj4NCj4NCj4gICAgICBEYXZpZA0KPg0KPg0KDQotLQ0KRGF2aWQgQmFsbA0K PGRhdmliYWxsQGNpc2NvLmNvbT4=