Re: [L2sm] [L3sm] Followup of RFC8049bis

[Qin Wu <[e-mail]>]

发件人: David Ball [mailto:[e-mail]]
发送时间: 2017年7月5日 19:47
收件人: Qin Wu; [e-mail]; [e-mail]
抄送: Benoit Claise (bclaise); [e-mail]
主题: 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

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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/l3sm



--

David Ball

<[e-mail]><mailto:[e-mail]>