Re-, After re-reading 8426, I think that you have a valid point. I went through the bunch of SPRING documents, but unless I’m mistaken none of them formally defines SR-TE.
The initial intent was to control the policy to build the underlay when SR is used: indicate that a TE topo is needed to run SR. That’s said, if any advanced policy instruction is needed in addition to SR, this can be handled as part of the service mapping I-D. Will remove sr-te from the draft. Thank you for pointing this. Cheers, Med De : Dhruv Dhody [mailto:[email protected]] Envoyé : mercredi 7 avril 2021 12:28 À : BOUCADAIR Mohamed TGI/OLN <[email protected]> Cc : [email protected]; Joe Clarke (jclarke) <[email protected]> Objet : Re: [OPSAWG] WG LC: L3NM and vpn-common documents Hi Med, On Wed, Apr 7, 2021 at 1:23 PM <[email protected]<mailto:[email protected]>> wrote: Hi Dhruv, Thank you for the review. Focusing on the vpn-common part: > draft-ietf-opsawg-vpn-common: > - Not sure about the difference between the identity "sr-mpls" and > "sr-te". Med: sr-mpls refers to RFC 8660, which states that TE is out of scope: The case where the outgoing label is not the top label and is part of a stack of labels that instantiates a routing policy or a traffic-engineering tunnel is outside the scope of this document and may be covered in other documents such as [ROUTING-POLICY]. sr-te refers basically to RFC8426. RFC 8426 does not look like the correct reference. It does not have a term called SR-TE. Also, the quoted text above from RFC8660 is about the forwarding behavior for Global SIDs. Moreover from the VPN point of view, do we need to distinguish between the use of a single global SID v/s a stack? Not sure. I thought maybe we use the term SR-policy but that is applicable for both SR-MPLS and SRv6. Thus not sure about it. References for both are provided in the module. > - Is there a reference for QinAny? Med: We failed to find a satisfying authoritative reference. Same here! :( Could the IEEE liaison help, or is it a lost cause! Also, should we use 'QinQ' and > 'QinAny' in the description, instead of 'qinq' and 'qinany'? Med: Fixed. > - Some of the references used in YANG are not listed in Section 9. > Example - IEEE Std 802.1Q, RFC 8453. > == Med: Fixed. Adding those has a side effect to call them out in the core text. Some text rearrangement was needed as you can see at: https://github.com/IETF-OPSAWG-WG/lxnm/commit/52e9a191b7adb3f8e90f6cf404518ef078dd1093. Some like to put a table of all references used in the YANG model in the core text to make this exercise easier :) Thanks! Dhruv Cheers, Med _________________________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
