Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

["Les Ginsberg (ginsberg)" <[e-mail]>]

Bruno -

Regarding the A-flag...
It may not matter much whichever way we decide - but the A-flag was invented because at the time (prior to RFC 7794) there was no way to determine from looking at a prefix reachability advertisement whether it was originated by the advertising node or had been leaked from another area.
If RFC 7794 had existed when the SR-MPLS draft was first being developed there would have been no need for the A-flag.

As regards Area-SID, there is no prefix to be leaked - so I do not see that the A-flag serves any useful purpose.
If you want it to be set just to be consistent with its use in PSP logic - OK - but I think this is unnecessary.

   Les


From: Lsr <[e-mail]> On Behalf Of [e-mail]
Sent: Thursday, July 30, 2020 9:46 AM
To: [e-mail]
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi authors,

Please find below some feedback for information. Feel free to ignore.

4.4.13.  The Area SID  https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13<https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4..4.13>

   "The following extensions to the Binding TLV are defined in order to
   support Area SID:

      A new flag is defined:

         T-flag: The SID directs traffic to an area.  (Bit 5)

         When T-flag is set:

            M and A flag MUST be clear"

My understanding is that the Area SID is installed in the FIB of all inside edge routers. Based on this, I would argue that the  A flag could and SHOULD be set

https://www.rfc-editor.org/rfc/rfc8667.html#name-flags-2
"A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the A bit in order to signal that the prefixes and SIDs advertised in the SID/Label Binding TLV are directly connected to their originators."
---
4.4.7.  Reachability TLVs   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.7


   If the Inside Area supports Segment Routing and the selected TLV

   includes a Prefix Segment Identifier sub-TLV (3) [RFC8667<https://tools.ietf.org/html/rfc8667>], then the

   sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the

   copy of the sub-TLV to indicate that penultimate hop popping SHOULD

   NOT be performed for this prefix.  The E-Flag SHOULD be reset in the

   copy of the sub-TLV to indicate that an explicit NULL is not

   required. The R-Flag SHOULD simply be copied.




May be it would be more generic to say that those prefix are handled as redistributed prefix.
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.2 and https://www.rfc-editor.org/rfc/rfc8667.html#EANDPFLAGS already defines the behaviour for respectively Prefix-SID propagation and P and E flags handling, so probably no need to re-specify:
When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a reachability advertisement originated by another IS-IS speaker, the router MUST set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs.
That would also cover for the handling of Prefix Attribute Flags sub-TLV RFC7794.

I would argue that the R-Flag MUST be set (rather than simply copied). As per https://www.rfc-editor.org/rfc/rfc8667.html#name-r-flag-and-n-flag

Best regards,
--Bruno



_________________________________________________________________________________________________________________________



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.