Re: [L3sm] Feedback on L3SM draft

[David Ball <[e-mail]>]

Thanks - additional comments inline (see [DB1]):

On 21/04/2016 08:56, [e-mail] wrote:
> Hi,
>
> Thanks for the comment, please find inline comments.
>
>
> -----Original Message-----
> From: L3sm [mailto:[e-mail]] On Behalf Of David Ball
> Sent: Wednesday, April 20, 2016 18:15
> To: [e-mail]
> Subject: [L3sm] Feedback on L3SM draft
>
> Hi,
>
> I would like to introduce myself as the editor of the MEF IP Service Attributes project.  In the MEF, we have been considering the latest L3SM draft (draft-ietf-l3sm-l3vpn-service-model-05) during the last quarter, and in that context and as requested in your recent liaison, I would like to provide some questions and comments.  Note that this is my personal feedback, not that of MEF.
>
> Some of my comments are for information only (I have marked these with "(I)").  Many others are questions to ensure I have understood the model correctly - in these cases, as well as answering my questions, it may be useful to add additional explanation to the draft to help other readers, even if no changes are needed to the yang module itself.
>
> * (I) Abstract: It is stated here, and again in Sn 4, that the intent of
>     this model is that it can be instantiated by a management system in
>     the SP, i.e. it contains all of the info needed to allow the
>     management system to configure the SP's network elements so as to
>     correctly provision the service.
>     Note that this is similar, but not identical, to the focus of the MEF
>     work, which is to define the set of attributes that must be
>     contractually (or otherwise) agreed between the SP and the subscriber.
>
> * Sn 5: The "bearer" is described as refering to the physical properties
>     of the attachment, as opposed to the protocol oriented properties.
>     Are L2 aspects considered to be physical properties or protocol
>     oriented properties?  For instance, suppose the attachment
>     is via a VLAN over an Ethernet LAG containing 2 physical Ethernet
>     interfaces: is the bearer the VLAN, the LAG, or the physical
>     interfaces?
>
> [SLI] The goal of the model is to focus on Layer 3. Bearer is just a reference to everything under layer 3, so as your example, VLAN is considered as bearer.
> One "issue" we have to deal with in L3SM, is that we cannot manage all the access types as it's really different from one provider to the other and there are plenty of accesses. Moreover it's not really a L3VPN topic.
> So two cases :
> - the customer orders an access separately of the L3VPN site, in this case, the bearer reference needs to be attached, so the customer provides a reference to an existing access to the provider.
> - the customer orders an access at the same time of the L3VPN site. The provider will need to provide an access type that fills the customer requirement in term of diversity, bandwidth, services ...
> The first option is here just in case the customer does not want to use an automated access election procedure but wants a really specific access type. This makes me thing that an "always-on" boolean may be necessary for some backup scenario ...

[DB1]
Ok this makes sense - yes I agree trying to cover all the possible cases 
is challenging and not really in the scope of the L3 service. It would 
be useful to add a bit more explanation about this (I guess in Sn 
5.2.7.1), in particular to mention that the bearer covers everything 
below layer 3.

> * Sn 5.1.1.4: Could you add an example of when hub-and-spoke-disjoint is
>     used?  Is it the same as having 2 hub-and-spoke VPNs where each hub
>     site belongs to a different VPN and all the spoke sites belong to both
>     VPNs?
> [SLI] Yes this is similar to the case you mention.

[DB1]
Is it similar or the same?  What is the difference?
What I am asking about is the real-life case where you would need 
hub-and-spoke-disjoint.

> * Sn 5.1.2: It is unclear to me how a Cloud identifier (e.g. "Cloud1")
>     is associated with a particular cloud service (say, Amazon Web
>     Services).
>     Is there an assumption that the management system that is
>     instantiating this yang model has auxilliary knowledge about the cloud
>     service that each Cloud ID is actually associated with (configured
>     by some means outside the scope of this model)?
> [SLI] That's the point. OSS needs some knowledge about what is Cloud1 and Cloud2, this can be hardcoded or retrieved from another system. The same happens with standard QoS or encryption profiles ...
>
>     For the subscriber to order a cloud service, they also need to know
>     what actual service each Cloud ID is associated with - is that also
>     assumed to be known by means outside this model?
> [SLI] Provider can communicate to customer the list of CloudIDs to be used. Is that an issue ?
[DB1]
Ok - no that's not an issue, although it would be useful to say 
explicitly in the draft that the association is provided to the customer 
by some other means.

> We cannot really define a list of clouds here ... I think we need to keep it flexible.
>
>
> * Sn 5.1.4: I was a bit confused by the description of extranet.  If
>     VPN A lists VPN B as an extranet, then the text states that the
>     relationship must be bi-directional.  However, the site-role leaf
>     means that it is not necessarily symmetric.  My interpretation is that
>     if VPN B has hub-and-spoke (or hub-and-spoke-disjoint) topology, then
>     sites in A might only be able to access certain sites in B (depending
>     on the specified role); however, those sites in B would always be able
>     to access all sites in A.  Is this interpretation correct?
> [SLI] Bi-directional does not mean symmetric here. It just mean that if you configure extranet in VPN A to access to VPN B, you don't need to configure the reverse (VPN B accessing to VPN A). Now in term of real communications between sites, the VPN topology will dictate it as you mentioned.

[DB1]
It would be useful to make that more explicit in the draft.

>     Presumably the requirements in Sn 5.2.1 are intended to also apply to
>     the site-role leaf for the extranet, in respect of the topology of the
>     VPN listed as the extranet?  It would be good to state that
>     explicitly.
> [SLI] Yes for sure. Will enhance text in future revision.
>
>
> * Sn 5.2.2.1.2: In the case of a site connected to multiple VPNs, how is
>     traffic received from the site mapped to the right VPN?
>     It is important to know which VPN the traffic maps to, not only to
>     ensure it is sent to the right destination, but also because different
>     VPNs might have different bandwidth or performance attributes.
>
> [SLI] No, attributes you are referring to are sites attributes, not VPN attributes.
> In multiVPN scenario, the same logical access is used to access to all VPNs : for instance, bandwidth is shared.

[DB1]
Sorry I was unclear; I was thinking of things like the bandwidth or 
latency transport constraints, which are per VPN.

>     As described later on (Sn 5.2.2.2), a VPN policy can be used with a
>     filter that limits the LANs that belong to each VPN (which implies
>     that a packet can be mapped to a VPN based on its source address);
> [SLI] Yes and no,  from a service point of view, this can be seen as source based VPN association.
> Now, in reality (device implementation),  it's still a destination based association, each LAN will be advertised with a different RT, so the return traffic is using a different VPN.

[DB1] Right, it is the service definition perspective I am most 
concerned with.

>     however, I don't think there is a requirement that filters are used to
>     ensure that each possible LAN only belongs to a single VPN.  Is the
>     intention that filters are used to partition the LANs, or can a packet
>     with a given source address potentially belong to multiple VPNs?
> [SLI] There is no limitation here, each LAN can belong to a single VPN, or a LAN can belong to multiple VPNs, or just some ... For instance, one use case (at least for us) is ToIP, where only Voice LANs need to be part of a customer Voice VPN, and the others are belonging to the regular customer IPVPN.
>
>     If so, is the implication that the destination address is looked up in
>     each VPN?  Is it possible that a route to the destination exists in
>     multiple VPNs?  How is the order of the VPNs in which to perform the
>     lookups determined in that case?
>     For instance, looking at the first example in Sn 5.2.2.2.2 (VPN
>     policy), when a packet is received from VPN3_Site2 at PE6, how does
>     PE6 determine whether to handle the packet as part of VPN2 or VPN3?
> [SLI] The IP destination is used. The destination IP can be part of VPN2 or VPN3.

[DB1]
Can the destination be part of VPN2 and VPN3?
If so, how does the PE determine which to use?

> * Sn 5.2.2.1.3: Both from the perspective of what the management system
>     needs to know to provision the SPs network, and from what needs to be
>     agreed between the SP an the customer, this "Sub VPN attachment" case
>     seems to be indistinguishable from treating it as separate sites.  The
>     text says: "It is similar than having separate sites instead that the
>     customer wants to share some physical components while keeping strong
>     isolation".  However, from a service definition perspective, whether
>     two separate sites happen to share the same physical infrastructure is
>     immaterial, and in fact this could (or should) be invisible to the SP.
>     I don't understand what additional value this "Sub VPN attachment"
>     case provides.
>
> [SLI] This is a discussion we already had about how to model SubVPN.
> Considering them as separate sites was evaluated but there was some need to correlate
> sites that belongs the the same sub-VPN. This is particularly true when the SP provides the access.
> The SP needs to know that the IP sites must be built on the same access.

[DB1]
Would this be captured by them both refering to the same bearer (or to a 
bearer that ultimately maps to the same access)?

> * Sn 5.2.3.1: In the case of a service-provider defined template, how
>     would the customer be aware of what the template contains?  Is it
>     assumed to be made available by some mechanism outside the scope of
>     this yang module?
>
> [SLI] The idea to have customer to create template, not really the provider.

[DB1]
The text says "a service provider defined template", so if that's not 
the intent then it probably needs to be updated.
In any case, the same question would exist the other way round: if the 
customer creates the template, how would the provider know what's in 
it?  I guess this is the same as the cloud IDs and QoS profiles, it's 
some mechanism outside the scope of the yang, right?

> * Sn 5.2.4: I think there is a conflict between the definitions in
>     section 2 and the values described in this section. According to
>     section 2, the "CE" is on the customer side of the SP-customer
>     boundary, which I take to mean it is owned and managed by the
>     customer.  Given this definition, it would seem that a
>     "provider-managed" service is impossible - if the provider manages a
>     CPE device that is not VPN aware, then that is not the "CE" according
>     to the definitions in section 2, it is the "PE".  The definitions in
>     section 2 don't seem to align with what is normally understood by "PE"
>     and "CE" in this case.
>
> [SLI] Agree, my mistake, I will need to update definitions in Section 2.
> It was a bad copy/paste.

[DB1]
Ok, thanks.

>    Furthermore, section 3 limits the scope of the model to BGP PE-Based
>     VPNs, so this case - where the "PE" (per section 2) is a CPE that is
>     not VPN aware - is out of scope per Sn 3.
> [SLI] Not sure to catch the case you mention here ..

[DB1]
Never mind, I think if you fix the definitions that will cover this.

>     I don't think that is the intent; this situation is clearly intended
>     to be in scope (especially as this is exactly the case described by
>     the example in Sn 6); so I think either the definitions in Sn 2 or the
>     scope statement in Sn 3 (or both) need to be modified.
>     Note that this impacts several other parts of the document: e.g. 5.2.5
>     refers to a "CE-customer" boundary, 5.2.7.2 refers to a "CE to LAN
>     connection", etc - neither of which makes sense given the current
>     definitions in section 2.  On the other hand, changing the definitions
>     may also have other impacts, e.g. site diversity, acccess diversity,
>     traffic protection, etc are described in terms of the CE-PE links, but
>     for provider-managed sites perhaps they are intended to apply to the
>     CE-customer links (or perhaps not)?
> [SLI] CE is located at customer premise whatever the management model.
> Site diversity ... always refers to CE-PE connection (customer site to provider network).

[DB1]
Ok - so in the provider-managed case, this is giving the customer 
visibility into the provider's network?

> * Sn 5.2.4: Assuming the above problem is fixed, it is not clear what
>     "comanaged" means or how that affects the rest of the model.  Where is
>     the demarcation between the SP and the subscriber in this case?
>     Also, in the case of provider-managed, wouldn't the management address
>     (of the CE??) be internal to the SP (i.e., it could be allocated in a
>     similar way to RTs and RDs)?  It's not something the customer needs to
>     be aware of, right?
> [SLI]
> co-managed means that it's provided and managed by the SP , but the customer can access it.
> Demarcation is the same as provider managed case. I will add more text to precise it.

[DB1]
Ok, thanks.

> * (I) Sn 5.2.5: For information, MEF members indicated that several
>     other protocols are in use that would need to be added to this list
>     (in particular, ISIS and EIGRP).
>
> [SLI] IS-IS as PE-CE ?

[DB1]
Yes.

> EIGRP is not really a standard protocol, it can be added through augmentation I think, a bit like HSRP.

[DB1]
Yes fair enough. :)

> * Sn 5.2.5.2: In this case, is the implication that the customer uses a
>     default route towards the SP?  How does the customer determine the
>     gateway address to use?
>     (Same question also applies in the VRRP and static cases).
>
> [SLI] Good point, the subnet-only option for static allocation of IP addresses causes an issue here.
> If customer uses "addresses" container, it allocates provider address so he knows the gateway.
> With dynamic allocation, like DHCP, gateway can be learned.
> We can remove the subnet-only option.

[DB1]
Ok - yes the subnet-only option caused us a lot of confusion so removing 
it would be good!
It would also be useful to say explicitly that the provider address or 
the address learnt through DHCP/SLAAC should be used as the default 
gateway when the routing protocol is set to "static" or "direct".

> * Sn 5.2.5.2: This seems to be describing a case where the SP-customer
>     link could be a multipoint link; for example, where the SP provides a
>     WiFi access point to a residential subscriber.  Is that right?
> [SLI] Why multipoint ?

[DB1]
In this case, the wifi access point would be a provider-managed CE. The 
customer could have multiple devices that connect to the CE over wifi; 
so, the SP-customer link is a multipoint connection.
(Note the CE is provider-managed in this example, so the SP-customer 
link is not the PE-CE link; the PE-CE link might still be P2P).

>     It seems like there would need to be several other restrictions in
>     this case - for example, the connection addressing would need to be
>     DHCP or SLAAC (since the static option can only be used to provide a
>     single address for the customer), and this likely only applies to
>     provider-managed sites.  Some P2P aspects like BFD and encryption
>     would need to be disabled.
>
> * (I) Sn 5.2.5.3: The use of VRRP should be invisible to the customer;
>     so this is an example of something that does not need to be agreed
>     between the SP and the customer, but which the management system in
>     the SP needs to provision in the PEs.
> [SLI] VRRP case is a bit tricky.
> This is the case where customer has direct LAN connections multihomed to two PEs, so there are two logical accesses.

[DB1]
There are certainly 2 L2 links, but you could view it as a single L3 
link (since the two PEs must also have L2 connectivity between them over 
the same LAN), and hence a single logical access.  From the CE's 
perspective, it only sees a single L3 peer (just one who's corresponding 
MAC address keeps changing).  Of course, from the provider's 
perspective, there are definitely 2 PEs...

> Now the customer wants only direct routing but with redundancy.
> I think we can deduce from routing protocol=direct + presence of the availability container that we need to implement VRRP.
> Does it work for you ?

[DB1]
Yes, that would work; alternatively, it could be covered as part of the 
bearer, or maybe even an explicit VRRP boolean under the network-access.

> * Sn 5.2.6.1: The QoS profile is described as the "outgoing QoS profile
>     to be applied" - if I understand that correctly, it means the QoS
>     profile only specifies egress policing, it does not specify any
>     ingress policing - is that correct?
>
> [SLI] Yes, only egress policing.
>
>
> * Sn 5.2.6.1.2: In the case of standard profiles, how does the
>     customer know what they are?  Is that assumed to be done by means
>     outside the scope of this yang module?
> [SLI] Yes communication needed between SP and customer.

[DB1]
It would be useful to make that explicit.

>     Also, the priority relates to strict priority queuing - is strict
>     priority queuing required when this yang module is used, or can other
>     mechanisms also be used?
> [SLI] The exact mechanism to be used does not really care here.
>  From a service point of view, we provide multiple level of priorities, and within each level, we can provide a guaranteed bandwidth.

[DB1]
That makes sense.  The text says "Priority-level is used to define 
strict priority queueing." - perhaps changing "is" to "can be" would 
soften this a little?

> * Sn 5.2.6.1.2: The rate-limit is described as "a percentage of the
>     global service bandwidth" - is the "global service bandwidth" the
>     value specified in the "svc-output-bandwidth" leaf?
>     Similarly, the guaranteed-bw-percent is "expressed as a percentage",
>     but it doesn't say what it is a percentage of.  Is this also a
>     percentage of the value in the "svc-output-bandwidth" leaf?
> [SLI] Yes it's a percentage of svc-output-bandwidth or input-bandwidth (depending if the access is symmetric in term of BW or not).
> I will add more text to precise it.

[DB1]
If it is egress policing only, wouldn't it always be the 
svc-output-bandwidth?  When would svc-input-bandwidth be used?

> * Sn 5.2.7: Some parameters can be configured at the site level or at
>     the network-access level; but it seems like certain parameters only
>     make sense at one or the other; for example, it is unlikely you would
>     want different routing protocols on different network access links,
>     but you might want to assign different metrics to different links.
>     How is this handled?
> [SLI] Well, this was an old discussion also.
> It looks that there is some SP using different protocols in multihoming scenarios (ex : BGP on one side, static on the other, or OSPF ...). That explain why we need routing protocol container at site network access level.

[DB1]
Ok.

> * Sn 5.2.7.2.1: In the case of DHCP (or SLAAC), is the assumption that
>     it is used to provide (at least) the customer address, subnet mask and
>     default gateway address?
>     Also is there an assumption that a static-address is used in the case
>     where the routing protocol is BGP?
> [SLI] Yes, we can precise it.

[DB1]
Thanks.

> * Sn 5.2.8: I found this description unclear - is the intent that this
>     information is all internal to the SP, and used to give information to
>     the management system; or is it intended to be a way for the customer
>     to provide hints to the SP, which the SP may choose to ignore?
> [SLI] That's the point.
> Service placement is up to the SP but customer can influence it especially for the diversity purpose.
> In case the SP provides diversity service it needs to fill it and must not ignore it.
>
> * Sn 5.2.8: My reading of this paragraph is that the SP can decide how
>     to connect each site based on any constraint, and that the ones listed
>     here are optional and are to be treated as hints by the management
>     system.  However, some of the following subsections have hard
>     requirements (MUSTs).  What is the intent here?
> [SLI] Diversity constraint is a constraint that the SP cannot ignore.
> After that SP is free to place the service based on its own policy.

[DB1]
Ok - maybe need a tweak to the text to make that clearer?

> * Sn 5.2.8.2: I am not sure how to interpret these requirements if the
>     sites have more than one network-access link (to different PEs).
>     Do they mean that two sites in the same site-group must have at least
>     one network-access link to a different PE/PoP, or that the PEs/PoPs
>     that network-access links connect to must be completely disjoint sets?
>
> [SLI] PEs/PoPs must be completely disjoint set. But I could agree that this is strong.
> In case of multihoming, "pe-diverse" applies between site-network-accesses.
>
>     Or do they only apply to sites with a single network-access link?
> [SLI] No, that should work with multihomed.

[DB1]
Ok, I think this should be made clearer in the requirements - the 
existing text just refers to sites not to site-network-accesses.

>     If two sites both have two network-accesses, then even if they are
>     connected to the same 2 PEs, a PE failure would not impact
>     connectivity to them or between them.
>     For example, is it allowed to have site A connected to PE 1 and PE 2,
>     and site B connected to PE 2 and PE 3, if they both are set to PE
>     diverse and are in the same site group?  What if site B is connected
>     to PE 1 and PE 2?
> [SLI] Customer does not require diversity in this case, because diversity is already provided by multihoming which is "pe-diverse" by default.

[DB1]
Agreed - but if an SP gets a request from the customer that asks for 
site diversity, they still need to know what to do with it.  From the 
above, it looks like neither of these cases would be allowed, right?

>     Also, what is the required behaviour if some sites in the site-group
>     are set to PE-diverse and some are set to PoP-diverse?
> [SLI] Good catch :)
> We need to precise the expected behavior.
> 1) We can consider diversity type+site-group as a group ID. So having a site A with pe-diverse group 10 and site B with pop-diverse group 10, will consider A and B not part of the same group, and no diversity will be applied between them.
> 2) We allow for mixing. If we have site A,B,C with pe-diverse group 10 and let's says that A is on PE1 PoP#1, B is on PE2 PoP#1, C is on PE3 PoP#4 ; now we add a new site D with pop-diverse group 10, this means that D cannot be implemented on PoP#1 and PoP#4.
> Any preference?

[DB1]
No personal preference; option 1 is simpler, but option 2 seems ok too.  
I think option 2 means: any site in the group that is set to pop-diverse 
must not share a PoP with any other site in the group, but 2 sites in 
the group that are both pe-diverse could be on different PEs in the same 
PoP, right?


> * Sn 5.2.8.3: Similar question here: what is the expected behaviour if
>     one access link is set to PE-diverse and one is set to PoP-diverse?

[DB1]
I think this case could be fixed by making this a per-site attribute 
rather than a per-network-access attribute.

>     Also is a "none" option needed, for when it's ok for both links to
>     terminate at the same PE?
> [SLI] "None" option is when the container does not exist. Does it work ? In this case yes, both can terminate on the same PE.

[DB1]
Ah, ok - that definitely needs to be mentioned!


> * Sn 5.2.8.3: I think there is a problem with this way of specifying
>     the availability behaviour based on access priorities. In the complex
>     example in the last paragraph, it says that if A1 and A2 fail, the
>     traffic will be load-shared on A3 and A4.  However, if only A1 fails,
>     the traffic would all be forced on to A2, right?  This is unlikely to
>     be desirable - probably what the customer wants is to always be
>     load-sharing on 2 links, unless all of A1 - A4 fail (i.e., if only A1
>     fails, then load-share on A2 and A3).  There doesn't seem to be a way
>     to specify that using access priorities.
>     Having said that, this may not be a problem in practice: the SPs in
>     MEF all indicated that they never have more than 2 links to a given
>     site.
>
> [SLI] We have some use case with more than two connections.
> The problem you describe is true but it's linked to the design chosen (so customer has to adapt the capacity planning).
> Most of the case I know are more multiple levels of backups, but the model is flexible and can provide anykind of design, that's why we wanted to illustrate it.

[DB1]
I'm not sure I understand this.  How would this model provide the design 
I described?

> * Sn 5.2.8.3.1: If I understand correctly, the difference between
>     traffic protection enabled and disabled would be in how quickly the SP
>     can restore traffic towards a site if one of the network-access links
>     fails - is that correct?  I'm not sure how useful this is without
>     putting some numbers in here - i.e. if the customer pays extra for
>     a service with traffic protection enabled, what traffic restoration
>     speed is the SP targeting or guaranteeing?
>
> [SLI] traffic protection is typically implementation of fast reroute technology.
> What SP is guaranteeing or not , is up to each SP ...

[DB1]
Yes of course, but the customer needs to know what it is.  Maybe that's 
outside the scope of the yang module?

>     Also, what is the expected behaviour if traffic protection is enabled
>     on one network-access link but disabled on another? Shouldn't it be
>     an attribute that applies to the site as a whole rather than to each
>     network-access link separately?
> [SLI] We cannot really do it per site, due to the subVPN case where a subVPN site may have it and others not.
> Agree that for multihoming, all logical access needs to have it.

[DB1]
Ok - so we still need to define what happens if one has it and another 
doesn't, right?

>     (I) For info: in MEF this would likely be covered by an SLS objective;
>     it would be up to the SP to determine whether they needed to enable
>     traffic protection or not in order to meet the SLS in the event of a
>     link failure, rather than the customer requesting this explicitly.
>
> [SLI] That's also a good way to do it.
> The issue is that some customer really wants to be precise in what is implemented.
>
> * Sn 5.3.1: In RFC 4364, this is called "Carrier's carrier" rather than
>     "Carrier supporting Carrier" - I think the latter is Cisco's name for
>     the same feature.  It would be better to use the RFC4364 name in this
>     draft.
> [SLI] Ack
>
>     Also in the yang module, it would be clearer to call the leaf
>     "carriers-carrier" or similar, rather than "mpls".
>
> * Sn 5.3.2: Some of these constraints are not clearly defined.  I assume
>     that the latency and jitter constraints specify the maximum latency
>     and jitter, whereas the bandwidth is the minimum bandwidth?  Do these
>     constraints apply to all received packets for all traffic classes?
> [SLI] It's independent of class of services.
>
>     I do not understand the site diversity constraint - how would a
>     path between 2 sites cross any other sites?  Does it mean "are not
>     crossing the same P routers"?  Or does it mean that the paths are
>     physically diverse?
> [SLI] If you consider a path between two PEs, it will cross multiple network sites (where we host PEs or P routers).
> For example, a path between NY and LA will maybe cross CHI, DEN and LV.
> If we want another path with site diversity, we must avoid crossing CHI, DEN and LV.

[DB1]
Ok, that makes sense - I was confused because everywhere else in the 
document, "site" means "customer site" but here it is being used with a 
different meaning.  Could we use a different word here? Would "PoP" work?

>     (I) In MEF, I expect that all of these constraints would be covered by
>     the SLS.
>
> * Sn 5.4: The text here mentions "if apply-template is done on service
>     container of a site", and the example also shows a service container
>     with an apply-template leaf - but in the yang module, there is no
>     apply-template leaf in the service container.  The yang only has
>     apply-template for the site and for network-accesses.
> [SLI] We need to fix it.
>
> * Sn 6: As described in Sn 5.2.5, the routing protocol specified in the
>     model applies to the SP-customer link; however, in the example
>     described in this section, it is described as applying to the PE-CE
>     link, even though the CE is provider-managed and so the SP-customer
>     link is between the CE and the customer (e.g. it says "Routing
>     protocols will also be configured on the PE, bgp will be used as
>     requested in the service model.") In the provider-managed case, the
>     routing protocol used between the CE and the PE would be internal to
>     the provider and not specified in the model.
>
> [SLI] Agree, this is something that we missed to fix when we changed the routing protocol scope from earlier version.
> Thanks for the catch.
>
>
> * Sn 8: What are the svc-input-bandwidth and svc-output-bandwidth?  I
>     think the svc-output-bandwidth may be related to the QoS profile (see
>     earlier comments), but what is the svc-input-bandwidth for?
> [SLI] It's used in case of asymmetric BW media like ADSL.
>
> * Sn 8: If MPLS is enabled (i.e. the CsC case), does the svc-mtu value
>     include the MPLS labels or just the IP packet?
>
> [SLI] it becomes MPLS BW because the service is no more IP.

[DB1]
Ok - can you clarify that in the text?

> * Sn 8: Is there ever a case where the "list routing-protocol" can
>     contain more than 2 entries (i.e., one for IPv4 and one for IPv6)?
>
> [SLI] You can use dynamic and static routing at the same time also.

[DB1]
Ah yes, that makes sense.

> * Sn 8: For the ip-connection, how is the "subnet-only" case used?  In
>     this case, how are the SP's and the customer's addresses assigned and
>     known?
>     Also should the "subnet" choice apply only when the
>     address-allocation-type is static (i.e., add a "when" statememt)?
>
> [SLI] Based on earlier mentioned point, I think we need to remove the subnet only.

[DB1]
Ok.

> * Sn 8: The OAM parameters are not described in Sn 5 - is this an
>     omission?
>     In the case of a holdtime specified with a profile, how would the
>     customer know what the contents of the profile is?
> [SLI] That's a miss ...

[DB1]
Ok.

Thanks!


     David


>
> Thanks,
>
>
>       David
>
> --
> David Ball
> <[e-mail]>
>
> _______________________________________________
> L3sm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/l3sm
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

-- 
David Ball
<[e-mail]>