Subject: Re: [L3sm] [Yang-multicast] Fwd: Yang-multicast post from [email-masked] requires approval

From: Qin Wu <[email-masked]>
Date: Tue, 19 Apr 2016 03:33:53 +0000

FYI.
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
发送 时间: 2016年4月5日 17:53
收件人: Xufeng Liu
抄送: Qin Wu
主题: RE: [Yang-multicast] Fwd: Yang-multicast post from [email-masked]<mailto:[email-masked]> requires approval

Hi Xufeng,

Thanks for the feedback.

Pls find some inline comments.

Best Regards,

Stephane

From: Xufeng Liu [mailto:[email-masked]]
Sent: Tuesday, March 29, 2016 15:36
To: LITKOWSKI Stephane OBS/OINIS
Cc: Qin Wu
Subject: FW: [Yang-multicast] Fwd: Yang-multicast post from [email-masked]<mailto:[email-masked]> requires approval

Hi Stephane,

Sorry that I did not realize that you are not on the list, so I’m sending it to you directly.

Thanks,

- Xufeng

From: Xufeng Liu [mailto:[email-masked]]
Sent: Friday, March 25, 2016 10:27 PM
To: 'Stig Venaas' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Yang-multicast] Fwd: Yang-multicast post from [email-masked]<mailto:[email-masked]> requires approval

Hi Stephane,

Overall good. I have a few questions and comments:

- Why union is used for rp-address, etc.? The union is already defined
  as inet:ip-address.
[SLI] This was to express that it could be an ipv6 or ipv4 RP address.
Do you want to propose something else ?

- leaf group is a type of {ipv4-address | ipv6-address}, which is not
  convenient to specify multiple groups at once. Many implementations
  use a group policy which can give a group range.

[SLI] Current we have a single list with [RP group] as keys.
I can define two nested list to address your requirement :
List rp-to-group-mapping where we define RP parameters like today , it will use only rp-address as key.
And instead of having a group leaf , I can create a list “groups” using group-id as key.
Does it work ?

- Don't know how detailed the server model wants to be. When
  anycast-rp is enabled, usually we need to specify the
  anycast-address and the rp-address. Not sure if we need these.
[SLI] Anycast RP config is only needed for provided managed RP, in this case , the RP address can be allocated by the provider and there is no need to mention it in the model. Does it work ?

- For the rp-discovery options, the details are not specified. Is it
  intentional to let the management system to fill in the details?

[SLI] We have identities for that :

identity auto-rp {
                                base multicast-rp-discovery-type;
                                description
                                "Base identity for auto-rp discovery type.";
                }
                identity static-rp {
                                base multicast-rp-discovery-type;
                                description
                                "Base identity for static type.";
                }
                identity bsr-rp {
                                base multicast-rp-discovery-type;
                                description
                                "Base identity for BDR discovery type.";
                }

- The model is not a device model, but it imports ietf-routing, which
  in turn imports ietf-interfaces. Should we avoid them? The only
  used imported reference is rt:address-family.

[SLI] Agree , we only use the address-family and also protocol types.
If we avoid it, we need to redefine all of them which is a possibility.
Thoughts ?

- Under a site container multicast, there is a leaf protocol-type,
  which specifies either host or router. In case of router, PIM will
  be enabled. Do we need to have the PIM parameters here? In case of
  host, do we need to specify the group information here?
[SLI] I do not know, do you think there is a need for customer specific parameters here ?

- Do we want to support M-LDP based signaling (RFC6388)?
[SLI] This is a provider data IMO, so no need to have this information in the model.

Thanks,

- Xufeng

From: Yang-multicast [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Friday, March 18, 2016 6:58 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Yang-multicast] Fwd: Yang-multicast post from [email-masked]<mailto:[email-masked]> requires approval

Hi

There was an email to the list that I failed to approve in time. Sorry. Please see the email below.

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:
Date: Thu, 25 Feb 2016 16:31:15 +0000
Subject: Please review multicast VPN part in L3SM
Hi DT,

We are working on L3VPN service model (not device config), and there is a multicast part in it.
Could you please have a look on what we propose for multicast VPN to ensure we are not missing a big thing ? There are multicast parameters for VPN and for the sites in dedicated containers.

https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/

Thanks,

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.