Subject: [L3sm] Feedback on L3SM draft

From: David Ball <[email-masked]>
Date: Wed, 20 Apr 2016 17:14:57 +0100

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?

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

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

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

* 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.
   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);
   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?
   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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* 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?
   Or do they only apply to sites with a single network-access link?
   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?
   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?

* 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?
   Also is a "none" option needed, for when it's ok for both links to
   terminate at the same PE?

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

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

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

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

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

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

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

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

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

Thanks,

     David

-- 
David Ball
<[email-masked]>

---

From: <[email-masked]>
Date: Thu, 21 Apr 2016 07:56:07 +0000

Hi,

Thanks for the comment, please find inline comments.

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of David Ball
Sent: Wednesday, April 20, 2016 18:15
To: [email-masked]
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.

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

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

[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 ?
We cannot really define a list of clouds here ... I think we need to keep it flexible.

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

   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.

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

   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. 

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

[SLI] The IP destination is used. The destination IP can be part of VPN2 or VPN3.

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

[SLI] The idea to have customer to create template, not really the provider.

[SLI] Agree, my mistake, I will need to update definitions in Section 2.
It was a bad copy/paste.

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

[SLI] CE is located at customer premise whatever the management model.
Site diversity ... always refers to CE-PE connection (customer site to provider 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.

[SLI] IS-IS as PE-CE ? 
EIGRP is not really a standard protocol, it can be added through augmentation I think, a bit like HSRP.

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

[SLI] Why multipoint ?

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

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

   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.

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

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

[SLI] Yes, we can precise it.

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

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

[SLI] Customer does not require diversity in this case, because diversity is already provided by multihoming which is "pe-diverse" by default.

   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?

[SLI] "None" option is when the container does not exist. Does it work ? In this case yes, both can terminate on the same PE.

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

[SLI] traffic protection is typically implementation of fast reroute technology.
What SP is guaranteeing or not , is up to each SP ...

   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.

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

[SLI] Ack

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

[SLI] We need to fix it.

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

[SLI] it becomes MPLS BW because the service is no more IP.

[SLI] You can use dynamic and static routing at the same time also.

[SLI] Based on earlier mentioned point, I think we need to remove the subnet only.

[SLI] That's a miss ...

Thanks,

     David

--
David Ball
<[email-masked]>

_______________________________________________
L3sm mailing list
[email-masked]
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.

---

From: David Ball <[email-masked]>
Date: Thu, 21 Apr 2016 15:00:57 +0100

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

> 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" boole…

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

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

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

> [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 i…

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

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

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

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

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

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

> [SLI] Agree, my mistake, I will need to update definitions in Section 2.

[DB1]
Ok, thanks.

> [SLI] Not sure to catch the case you mention here ..

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

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

> Demarcation is the same as provider managed case. I will add more text to precise it.

[DB1]
Ok, thanks.

>     (in particular, ISIS and EIGRP).

[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. :)

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

>     WiFi access point to a residential subscriber.  Is that right?

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

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

> I think we can deduce from routing protocol=direct + presence of the availability container that we need to implement VRRP.

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

> [SLI] Yes communication needed between SP and customer.

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

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

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

> 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 si…

[DB1]
Ok.

> [SLI] Yes, we can precise it.

[DB1]
Thanks.

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

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

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

> 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 1…

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

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

> [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!

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

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

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

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

> [SLI] it becomes MPLS BW because the service is no more IP.

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

> [SLI] You can use dynamic and static routing at the same time also.

[DB1]
Ah yes, that makes sense.

> [SLI] Based on earlier mentioned point, I think we need to remove the subnet only.

[DB1]
Ok.

>     customer know what the contents of the profile is?

[DB1]
Ok.

Thanks!

     David

-- 
David Ball
<[email-masked]>

---

From: <[email-masked]>
Date: Thu, 21 Apr 2016 15:26:40 +0000

More inline , I stripped the agreed part

-----Original Message-----
From: David Ball [mailto:[email-masked]] 
Sent: Thursday, April 21, 2016 16:01
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [L3sm] Feedback on L3SM draft

[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.
[SLI2] From a service point of view, it's the same. From an implementation point of view, you can implement hub-spoke-disjoint in multiple ways.
I think there are very few use case (I remember at least one :) ), but this exist.

> [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.
[SLI2] I already updated the draft with a new paragraph regarding the external identifiers.

[DB1]
[SLI2] Done

> 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.
[SLI2] In multiVPN case, in most of the case you have a multiVPN site  that will take to different destination that are not part of the same multiVPN.
As an example, let's take site #1 which is multiVPN in VPN#A and #B. We have site#2 which is multiVPN #A and #C and site#3 which is multiVPN #B and #D.
If VPN#A express a transport constraint for site#1 <-> site#2, there is no ambiguity : for example, in VRF where site#1 is connected, there will be a TE tunnel to reach the PE connecting site#2 and BGP resolution will be done through this TE tunnel.
There is a "technical complexity" where site#1 is multiVPN in A and B and site#2 is multiVPN in A and B also with different transport constraint expressed in VPN A and B between the two sites. Honestly this does not really make sense IMO. But  policy based routing (including source based) is necessary at ingress to map to the correct TE tunnel (only in case LAN is used to identity the VPN belonging).

[DB1]
Can the destination be part of VPN2 and VPN3?
If so, how does the PE determine which to use?
[SLI2] In L3VPN, it's a single route to reach the destination in both VPNs, so there is no need to choose.

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

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

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

[SLI2] There is a misnaming here, it's bit a template (like site-template), it's a profile, like for cloud-access it requires external communication.

> 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?
[SLI2] Why do you think that ?

>     (in particular, ISIS and EIGRP).

[DB1]
Yes.
[SLI2] This requires a more global consensus I think ...

> 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".
[SLI2] Ok

>     WiFi access point to a residential subscriber.  Is that right?

[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).
[SLI2] Today we only manage P2P connection.

> 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...
[SLI2] When using VRRP, you have two layer 3 accesses and on top you will add the redundancy with a VIP.

> I think we can deduce from routing protocol=direct + presence of the availability container that we need to implement VRRP.

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

>  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?
[SLI2] Ok

> 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?
[SLI2] If you think PE-CE, output-bw will be used on CE side (CE to PE), input will be used at PE side (PE to CE).

[DB1]
[SLI2] Done

> [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.
[SLI2] I added more text in the site-network-access part.

> [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?
[SLI2] If customer requests diversity with multihoming, diversity will be enforced in addition to multihoming diversity leading to stronger constraint.
I will add more text to explain it.

[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?
[SLI] Right, I will clarify with option 2

>     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.
[SLI2] We cannot remove diversity from site-network-access as it is required for multihoming.

[DB1]
Ah, ok - that definitely needs to be mentioned!
[SLI2] Thinking more about it, I finally prefer the "none" approach. It's added now.

> 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?
[SLI2] It does not. If A1 fails, traffic will go to A2, so A2 needs to have sufficient capacity.

> 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?
[SLI2] Yes it is outside.

> 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?
[SLI2]
Right, this subVPN case still bring some complexity unfortunately, maybe we have to rethink again if we took the right approach.

> 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?
[SLI2] I will find a new naming

[DB1]
[SLI2] Done

---

From: David Ball <[email-masked]>
Date: Thu, 28 Apr 2016 12:42:26 +0100

Hi Stephane,

Apologies for the slow response, I have been at the MEF meeting this 
week and couldn't find a moment to look at this.  Responses inline, I've 
stripped out the agreed parts.

> I think there are very few use case (I remember at least one :) ), but this exist.

[DB2] Yes agreed there are lots of ways to implement it; if it's the 
same from a service definition perspective then that would be useful to 
mention.

> [SLI2] I already updated the draft with a new paragraph regarding the external identifiers.

[DB2] Great, thanks!

> If VPN#A express a transport constraint for site#1 <-> site#2, there is no ambiguity : for example, in VRF where site#1 is connected, there will be a TE tunnel to reach the PE connecting site#2 and…

[DB2] Right, there are no issues in this case.

> There is a "technical complexity" where site#1 is multiVPN in A and B and site#2 is multiVPN in A and B also with different transport constraint expressed in VPN A and B between the two sites.

[DB2] This is the case I'm asking about.

> Honestly this does not really make sense IMO. But  policy based routing (including source based) is necessary at ingress to map to the correct TE tunnel (only in case LAN is used to identity the VPN belonging).

[DB2] If it really doesn't make sense, then I think it would be good to 
add a requirement to say that it MUST not be done.  If it is allowed, 
then I think we need to say, from a service definition perspective, 
which VPN's constraints are applied; e.g. we could define some order for 
the VPNs and say that the first one that connects to the destination is 
used to apply the constraints.

> [SLI2] In L3VPN, it's a single route to reach the destination in both VPNs, so there is no need to choose.

[DB2]  Agreed, in implementation terms that is normally how it is done - 
it would be a single VRF.  I was asking more from a service definition 
perspective.

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

[DB2]
Ok - in that case it looks to me like the subVPN case isn't needed, i.e. 
you could model it as separate sites and infer from the fact they refer 
to the same bearer that they need to be correlated onto the same 
access.  But I don't want to re-open old discussions; if there a 
consensus that subVPN is useful then that's ok.

> [SLI2] There is a misnaming here, it's bit a template (like site-template), it's a profile, like for cloud-access it requires external communication.

[DB2]
Ok.

> [SLI2] Why do you think that ?

[DB2] If the CE is provider-managed, then logically the CE/PE links are 
part of the provider's network/responsibility, but the customer would 
still have visibility as to whether they terminate on different PEs or 
different PoPs.  I think that's fine, it's just an interesting point to 
note.

> [SLI2] This requires a more global consensus I think ...

[DB2]
Sure - we can always add it as an augment if it turns out to be needed.

> [SLI2] Today we only manage P2P connection.

[DB2]
Ok.

> [SLI2] When using VRRP, you have two layer 3 accesses and on top you will add the redundancy with a VIP.

[DB2]
Agreed, but it's a single LAN, right?

> [SLI2] If you think PE-CE, output-bw will be used on CE side (CE to PE), input will be used at PE side (PE to CE).

[DB2]
Ok, perhaps we are talking at cross purposes.
By egress, I mean traffic from the provider towards the customer, and by 
ingress I mean traffic from the customer towards the provider.  So I 
understood that it is egress policing only, i.e. meaning only from the 
provider towards the customer.  Is that right?
Similarly I thought "output" would be provider to customer and "input" 
would be customer to provider, but your description is the other way round.
Probably we should define these terms more carefully if they are open to 
misinterpretation.

> [SLI2] We cannot remove diversity from site-network-access as it is required for multihoming.

[DB2] I meant if you move it to be a per-site attribute, the same value 
would apply to all of the network accesses for the site.  It doesn't 
need to be specified separately for each network access.

> [SLI2] Thinking more about it, I finally prefer the "none" approach. It's added now.

[DB2]
Ok, thanks.

> [SLI2] It does not. If A1 fails, traffic will go to A2, so A2 needs to have sufficient capacity.

[DB2]
Ok - are there no cases with this type of design?  I would think you 
would want a way to model this, e.g. specify the number of links that 
should be active.

> [SLI2] Yes it is outside.

[DB2]
Ok, could you add some text to clarify that?

> Right, this subVPN case still bring some complexity unfortunately, maybe we have to rethink again if we took the right approach.

[DB2]
I will leave it to you and the other people involved in that discussion 
to decide whether to re-open it; as I said, I don't see the need for the 
subVPN case but I don't want to disrupt the consensus.

> [SLI2] I will find a new naming

[DB2]
Ok, thanks.

>> [SLI] It's used in case of asymmetric BW media like ADSL.

[DB2]
Right, but what behaviour is implied or required if a particular value 
is specified?  I think a bit more explanation would help readers 
understand how to use these values.

     David

-- 
David Ball
<[email-masked]>

---

From: <[email-masked]>
Date: Fri, 29 Apr 2016 08:38:23 +0000

More inline

-----Original Message-----
From: David Ball [mailto:[email-masked]] 
Sent: Thursday, April 28, 2016 13:42
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [L3sm] Feedback on L3SM draft

[DB2]
Ok - in that case it looks to me like the subVPN case isn't needed, i.e. 
you could model it as separate sites and infer from the fact they refer to the same bearer that they need to be correlated onto the same access.  But I don't want to re-open old discussions; if there a consensus that subVPN is useful then that's ok.

[SLI] I have still some concern on the current modeling of subVPN. subVPN is needed for sure, there are plenty of usage in real world, now the question is how to model it. I think we can reopen the discussion.

> [SLI2] Why do you think that ?

[DB2] If the CE is provider-managed, then logically the CE/PE links are part of the provider's network/responsibility, but the customer would still have visibility as to whether they terminate on different PEs or different PoPs.  I think that's fine, it's just an interesting point to note.
[SLI] Ok

[DB2]

[SLI] I would prefer augmentation for this one.

[DB2]
[SLI] Right , single LAN

[DB2]
Ok, perhaps we are talking at cross purposes.
By egress, I mean traffic from the provider towards the customer, and by ingress I mean traffic from the customer towards the provider.  So I understood that it is egress policing only, i.e. meaning only from the provider towards the customer.  Is that right?
Similarly I thought "output" would be provider to customer and "input" 
would be customer to provider, but your description is the other way round.
Probably we should define these terms more carefully if they are open to misinterpretation.
[SLI] I fixed the text to clearly describe it.

> [SLI2] We cannot remove diversity from site-network-access as it is required for multihoming.

[DB2] I meant if you move it to be a per-site attribute, the same value would apply to all of the network accesses for the site.  It doesn't need to be specified separately for each network access.

[DB2]
[SLI] Ok will add some

> Right, this subVPN case still bring some complexity unfortunately, maybe we have to rethink again if we took the right approach.

[DB2]
I will leave it to you and the other people involved in that discussion to decide whether to re-open it; as I said, I don't see the need for the subVPN case but I don't want to disrupt the consensus.
[SLI] As pointed, I'm open to reevaluate how subVPN is modeled.

>> [SLI] It's used in case of asymmetric BW media like ADSL.

[DB2]
Right, but what behaviour is implied or required if a particular value is specified?  I think a bit more explanation would help readers understand how to use these values.
[SLI]
I added more text to explain how it should be used.

     David

--
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Fri, 29 Apr 2016 15:47:55 +0100

Thanks Stephane.  Will you be publishing a new update to the draft with 
the new text?

     David

-- 
David Ball
<[email-masked]>