Re: [L3sm] Followup of RFC8049bis

[David Ball <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/l3sm

-- 
David Ball
<[e-mail]>