Hi Med, I think that you are good to go.
Thanks for accommodating my comments. Regards, Rob > -----Original Message----- > From: mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > Sent: 13 July 2021 17:04 > To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg-l3sm- > l3nm....@ietf.org > Cc: opsawg@ietf.org > Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09 > > Re-, > > Please see inline. > > Cheeers, > Med > > > -----Message d'origine----- > > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com] > > Envoyé : mardi 13 juillet 2021 17:55 > > À : BOUCADAIR Mohamed INNOV/NET > <mohamed.boucad...@orange.com>; > > draft-ietf-opsawg-l3sm-l3nm....@ietf.org > > Cc : opsawg@ietf.org > > Objet : RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09 > > > > Hi Med, > > > > Looking at the diff, I think that you have a typo for "oubound". > > [Med] Will be fixed. > > > > > But just to check, the "inbound-rate-limit" and "inbound-bandwidth" > > both act in the same direction, right? > > [Med] Yes. The text says inbound-rate-limit is a % of inbound-bandwidth. > > The text also indicates that the direction is from the perspective of the > customer site. That definition is also inherited from the common module. We > don't revert the directions to ease the mapping between L3SM and L3NM. > > > That was the consistency > > that I was striving for. Normally, when I think of a QoS policy as > > acting on say a PE interface, I think that inbound/outbound would > > have the reverse sense to have the input-bandwidth/outbound- > > bandwidth is described. I think that it would be good for these > > directions to be consistency if possible, but at a minimum the > > description needs to be very clear and using input vs inbound > > perhaps makes more sense if they are acting in different directions. > > > > Thanks, > > Rob > > > > > ________________________________________________________________ > _________________________________________________________ > > 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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
