[L2sm] R: Ignas Bagdonas' Yes on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)

[Fioccola Giuseppe <[e-mail]>]

Hi Ignas,
Thank you for the good opinion of the document.
We will address your comments and nits in the next revision.

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: Ignas Bagdonas [mailto:[e-mail]] 
Inviato: martedì 3 aprile 2018 19:42
A: The IESG
Cc: [e-mail]; Adrian Farrel; [e-mail]; [e-mail]; [e-mail]
Oggetto: Ignas Bagdonas' Yes on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)

Ignas Bagdonas has entered the following ballot position for
draft-ietf-l2sm-l2vpn-service-model-09: Yes

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-l2sm-l2vpn-service-model/



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

Authors, thank you for the detailed and thorough service model, especially for sections 6 and 7, it shows a good example to follow for model development.

A few comments and nits:

References to NMDA (8342) and tree diagrams (8340).

s2: VPWS definition seems to have a missing word - established as a logical [connection?] through a PSN.

s2: B-U-M vs BUM abbreviation, BUM seems to be more widely used in VPLS and EVPN references.

s3.1: IPLS reference RFC 7436.

s/VxLAN/VXLAN throughout the document.

s5.2.1: s/leave/leaf.

s5.2.1: references to E-Line and E-LAN would be good to have, MEF 6.

s5.2.2.4: MAC-VRF, s/arerequired/are required

s5.2.2.4: H&S disjoint topology would require more than two RTs in total, one per hub and at least one for sites.

s5.2.5: first paragraph: three frame types are supported - could you clarify?
Did you mean three frame types need to be supported?

s5.3: Terminology - exterior interfaces vs ACs.

s5.3: last paragraph: the site may support single homed or multi-homed [access?] - seems to be a word missing.

s5.3.2.2.1: s/802.1AH/802.1ah, a reference would be good.

s5.3.2.2.3: Micro-BFD reference RFC7130.

s5.3.2.2.6: cfp-802.1-ag vs cfm-8021-ag

s5.6.2: s/ALPHA-2/ISO 3166.

s5.10.1: s/dot1p/802.1p (or 802.1D).

s5.10.3: CE to CE frame modification - why SHOULD NOT form is used? What would happen if it  gets modified - as there is a common practice of not trusting customer CoS marking.

s5.15: s/REST/RESTCONF

s5.16.1, 5.16.2, 5.16.3: the use of EBGP, MP-BGP terms - it is just BGP, does it need to be emphasized?

s6: s/operatorpolicy/operator policy

s6: s/itscontrol/its control

s6: NETCONF/YANG ecosystem - maybe just YANG based ecosystem?

s7: s/Netconf/NETCONF



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.