Re: [OPSAWG] WG LC: L3NM and vpn-common documents

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-bounces@ietf.org> On Behalf Of tom petch
Sent: 08 April 2021 17:11
To: Dhruv Dhody <dhruv.ietf@gmail.com>; mohamed.boucadair@orange.com
Cc: opsawg@ietf.org; Joe Clarke (jclarke)
<jclarke=40cisco.com@dmarc.ietf.org>
Subject: Re: [OPSAWG] WG LC: L3NM and vpn-common documents

From: OPSAWG <opsawg-bounces@ietf.org> on behalf of Dhruv Dhody
<dhruv.ietf@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.boucadair@orange.com<mailto:mohamed.boucadair@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