Hi, You all might like to look at draft-ietf-teas-rfc3272bis
That's a long document, and although any review would be very much welcomed, the key is to look at the "components" of TE as discussed in section 1.2: policy path steering, and resource management. It is "helpful" to describe something as TE only when all elements are present, and to use the names of the components when they are not all in use. 4.1.16 of draft-ietf-teas-rfc3272bis is specifically about SR Comments on draft-ietf-teas-rfc3272bis could usefully be directed to the TEAS list. Cheers, Adrian -----Original Message----- From: OPSAWG <opsawg-boun...@ietf.org> On Behalf Of tom petch Sent: 08 April 2021 17:11 To: Dhruv Dhody <dhruv.i...@gmail.com>; mohamed.boucad...@orange.com Cc: opsawg@ietf.org; Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org> Subject: Re: [OPSAWG] WG LC: L3NM and vpn-common documents From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Dhruv Dhody <dhruv.i...@gmail.com> Sent: 07 April 2021 11:27 One comment on sr-te inline under <tp> Hi Med, On Wed, Apr 7, 2021 at 1:23 PM <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> 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". <tp> sr-te is used in the te world. There is even an I-D all about it, draft-ietf-teas-yang-sr-te-topo te has presence containers (not identity) for the different topologies and so defines one for sr-mpls; no need to specify te in that, te can be taken for granted in this WG! May be one day OPSAWG and TEAS will overlap and more will be needed:-) Tom Petch 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/52e9a191b7adb3f8e90f6cf404518e f078dd1093. 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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
