Subject: [L3sm] Followup of RFC8049bis

From: Qin Wu <[email-masked]>
Date: Mon, 3 Jul 2017 09:52:00 +0000

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)

---

From: David Ball <[email-masked]>
Date: Wed, 5 Jul 2017 12:46:51 +0100

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:
> 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
>
> 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.
>
> _______________________________________________
> L3sm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l3sm

-- 
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Thu, 6 Jul 2017 13:05:00 +0100

Hi Qin,

> 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
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Mon, 10 Jul 2017 13:47:05 +0000

发件人: David Ball [mailto:[email-masked]]
发送时间: 2017年7月5日 19:47
收件人: Qin Wu; [email-masked]; [email-masked]
抄送: Benoit Claise (bclaise); [email-masked]
主题: 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<https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-01#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:
     *   Agreed no change needed
     *   Agreed no change needed
     *   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.

     *   Addressed in the new draft
     *   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.

     *   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.

     *   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.

     *   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.

     *   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:
     *   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,:), but I have clarified this to you at the beginning. I would like to hear what L3SM Design Team think about this?

     *   Addressed in the new draft - customer can request either a number of addresses or an explicit list of address ranges.
     *   Agreed no change needed
     *   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

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

[email-masked]<mailto:[email-masked]>

--

David Ball

<[email-masked]><mailto:[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Mon, 10 Jul 2017 13:48:43 +0000

-----邮件原件-----
发件人: David Ball [mailto:[email-masked]] 
发送时间: 2017年7月6日 20:05
收件人: Qin Wu; [email-masked]
主题: Re: [L2sm] [L3sm] Followup of RFC8049bis

Hi Qin,

> 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
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Mon, 10 Jul 2017 15:01:32 +0100

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

-- 
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Tue, 11 Jul 2017 12:09:48 +0100

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:[email-masked]]
> *发送时间:*2017年7月5日19:47
> *收件人:*Qin Wu; [email-masked]; [email-masked]
> *抄送:*Benoit Claise (bclaise); [email-masked]
> *主题:*Re: [L3sm] Followup of RFC8049bis
>
> Thanks Qin.
>
> 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.
>
>     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.”
>
> “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.
>
>       managed.  See Section 6.10 
> <https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-01#section-6.10>.
>
> 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.
>
> [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
>
> “
>
> wants to share some physical components while maintaining strong 
> communication isolation between the affiliates.
>
> ”
>
> I think this is sufficient. If you think we should further limit 
> subVPN to the same bearer and same CPE, please let me know.
>
>  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.
>
> [Qin]: Agree, do you think section 6.1 “Features and Augmentation” is 
> sufficient to address your comment with any text change.
>
> 11. Can specify different performance objectives by using more
>     classes, no change needed
>     specified differently at each end.  Should the SP take the higher
>     or lower value?
>
>      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.
>
>      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.
>
> 13. I didn't see an answer from anyone on why the BFD parameters can
> [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.
>
>         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?
>
>        [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.
>
>   [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
>
>     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
>
>     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.
>
>     [email-masked] <mailto:[email-masked]>
>
> <[email-masked]> <mailto:[email-masked]>

-- 
David Ball
<[email-masked]>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 12 Jul 2017 17:44:54 +0900

Hi David,

>*	All information that needs to be exchanged between the SP and the Customer?

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:[email-masked]] On Behalf Of David Ball
Sent: Tuesday, July 11, 2017 8:10 PM
To: Qin Wu; [email-masked]
Cc: Benoit Claise (bclaise); [email-masked]
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

	Thanks Qin.

	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.

	      service.

	      site.

	      managed.  See Section 6.10 <https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-01#section-6.10> .

	”

	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.

	8.	You agreed to add some additional explanation about MTU, but I didn't see any changes in the draft?

	“

	     leaf svc-mtu {  

	       type uint16;  

	       units bytes;  

	       mandatory true;  

	       description  

	”

	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?

	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.

		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.

	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.

		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.

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

	Thanks,

	    David

		Hi, All:

		Regards!

		Qin (on behalf of team)

---

From: David Ball <[email-masked]>
Date: Wed, 12 Jul 2017 10:33:13 +0100

Hi Kenichi,

> 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.

> 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?

>     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

-- 
David Ball
<[email-masked]>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 13 Jul 2017 19:44:34 +0900

Hi David,

See comments inline [KO], please.

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Wednesday, July 12, 2017 6:33 PM
To: Ogaki, Kenichi; 'Qin Wu'; [email-masked]
Cc: 'Benoit Claise (bclaise)'; [email-masked]
Subject: Re: [L3sm] Followup of RFC8049bis

Hi Kenichi,

> 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.

> 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.

>     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

--
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Thu, 13 Jul 2017 12:29:53 +0100

Hi Kenichi,

> 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
<[email-masked]>

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 14 Jul 2017 17:05:28 +0900

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:[email-masked]] On Behalf Of David Ball
Sent: Thursday, July 13, 2017 8:30 PM
To: Ogaki, Kenichi; 'Qin Wu'; [email-masked]
Cc: 'Benoit Claise (bclaise)'; [email-masked]
Subject: Re: [L3sm] Followup of RFC8049bis

Hi Kenichi,

		

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

---

From: David Ball <[email-masked]>
Date: Tue, 18 Jul 2017 12:56:15 +0100

Qin, do you agree here?  Could we put some statement like this in section 5?

     David

-- 
David Ball
<[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Jul 2017 15:36:33 +0000

In trip, will ping all other L2SM design team members for this, and get back to you.

-Qin
________________________________________
发件人: David Ball [[email-masked]]
发送时间: 2017年7月18日 19:56
收件人: Ogaki, Kenichi; Qin Wu; [email-masked]
抄送: 'Benoit Claise (bclaise)'; [email-masked]
主题: Re: [L3sm] Followup of RFC8049bis

     David

--
David Ball
<[email-masked]>