Subject: [L3sm] Mirja Kühlewind's No Objection on draft-ietf-l3sm-l3vpn-service-model-18: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 26 Oct 2016 07:23:55 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-l3sm-l3vpn-service-model-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please spell out acronyms, e.g. OSS, CLI,ASM, SSM, RP, DHCP, OAM , BFD,
LIME, VRF and many more... That would at least help me a lot :-)

Two question mainly on the transport constraints part (sec 5.13.2):

1) I don't really understand why there is bandwidth as a service
parameter (section 5.12.1) and a transport constraint on bandwidth. Isn't
that the same? Can you explain!

2) There is a transport constraint on path-diversity. Shouldn't that be a
side specific parameter because that information in needed when placement
is considered? And respectively isn't side-diversity already covered by
Site network accesses parameters (sec 5.3.2)?

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Oct 2016 16:01:29 +0100

Hi Mirja,

> that the same? Can you explain!

5.12.1 describes the CE-PE connections.
5.13.2 describes the site-to-site flows.

One CE-PE connection is likely to support multiple site-to-site flows. It is useful for an operator to know more than just the CE-PE behavior especially if some site-to-site flow has especially demanding characteristics.

I think that the intros to 5.12.1. and 5.13.2 are clear about what they are describing.

> Site network accesses parameters (sec 5.3.2)?

There is a dependency, but there is a difference. Site multihoming is a site property. As the text in 5.13.2 says, you can't have path diversity without site multihoming. But site multihoming does not require that path diversity is used. Normally you would establish just one site-to-site path for any pair of sites (using, for example, a best path choice). The path diversity object allows the customer to request establishment of diverse paths for a specific site-to-site relationship where both sites are multihomed. How the customer uses these paths (resilience, load balancing, redundant traffic) is up to the customer.

Cheers,
Adrian
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 26 Oct 2016 17:18:23 +0200

Hi Adrian,

one more question...

> One CE-PE connection is likely to support multiple site-to-site flows. It is useful for an operator to know more than just the CE-PE behavior especially if some site-to-site flow has especially dem…
Wouldn't it be help to know if there are e.g. requirements on the max latency 
for the CE-PE connection?

> There is a dependency, but there is a difference. Site multihoming is a site property. As the text in 5.13.2 says, you can't have path diversity without site multihoming. But site multihoming does…

Okay,
Mirja

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Oct 2016 16:29:50 +0100

Hello again,

> > One CE-PE connection is likely to support multiple site-to-site flows. It is useful
> for an operator to know more than just the CE-PE behavior especially if some
> site-to-site flow has especially demanding characteristics.
> >

Not sure:
- how this would figure in the service provision
- what you could do with the information

On the whole, the CE-PE link is a physical attachment. If I ask for a specific latency on that link, what can the operator do about it (apart from varying the speed of light:-)? Perhaps there would be queuing mechanisms that could be varied in the PE, but it sounds complex.

On the other hand, the CE-PE link forms only part of the site-to-site path with most of the pieces that contribute to latency being within the service provider's network and with path choice being a major influence on the resultant e2e latency.

Now, it is possible that in the case of a multihomed site, there might be some choice about which CE-PE connection to use to achieve a low latency path, but that choice can be left up to the provider who is trying to construct the site-to-site path.

Best,
Adrian

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 26 Oct 2016 18:18:40 +0200

Hi,

see below.

> On the whole, the CE-PE link is a physical attachment. If I ask for a specific latency on that link, what can the operator do about it (apart from varying the speed of light:-)? Perhaps there would…
I was rather thinking about end-to-end delay, assuming that an CE-PE link 
could actually have multiple psychical hops. But maybe I'm think to 
complicated here and that's not what's happen in reality...

> Now, it is possible that in the case of a multihomed site, there might be some choice about which CE-PE connection to use to achieve a low latency path, but that choice can be left up to the provid…

Yes, that part is clear :-)

Thanks,
Mirja

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Oct 2016 19:35:47 +0100

Mirja, I may be wrong, but I don't think there are multiple hops (at layer 3) between CE and PE. They are directly connected routers.

So matters of choice/control for customers are limited to issues like latency and really only apply to the end-to-end (site-to-site) paths as shown in section 5.13.2

Cheers,
Adrian

> >>> One CE-PE connection is likely to support multiple site-to-site flows. It is
> >>> useful for an operator to know more than just the CE-PE behavior especially
> >>> if some site-to-site flow has especially demanding characteristics.
> >>
> > On the whole, the CE-PE link is a physical attachment. If I ask for a specific
> > latency on that link, what can the operator do about it (apart from varying the
> > speed of light:-)? Perhaps there would be queuing mechanisms that could be
> > varied in the PE, but it sounds complex.
>