Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

["Acee Lindem (acee)" <[e-mail]>]

Hi Peter, 

This is in response to the previous Email on your suggested text. 

On 5/26/20, 4:26 AM, "Peter Psenak" <[e-mail]> wrote:

    Hi Alvaro,

    please see inline (##PP)

    On 22/05/2020 16:59, Alvaro Retana wrote:
    > On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote:
    > 
    > 
    > Peter:
    > 
    > Hi!
    > 
    > 
    >> With respect to Alvaro's clarification, your answer for (1) makes sense;
    >> thanks! I think Alvaro has offered to help work out what (if any)
    >> additional text we might want to be sure that the answer to (2) is clear in
    >> the document.
    > 
    > I think that #1 is where some clarification could be useful. :-)
    > 
    > 
    > I'm including both ISIS and OSPF suggestions below to consolidate the
    > discussion.
    > 
    > 
    > ...
    >>> My interpretation of Ben's question is two-fold:
    >>>
    >>> (1) Would ISIS routers normally propagate the information to a
    >>> different level? The ELC is a new prefix attribute flag -- are prefix
    >>> attributes always propagated (unchanged) to other levels? If so, then
    >>> the requirement (MUST) is not needed. My reading of rfc7794 is that
    >>> the propagation is optional...
    >>
    >> depends on the attribute or a bit. Some are propagated some are not.
    >> That's why we are saying this one MUST be preserved.
    > 
    > Right.
    > 
    > For ISIS I think the current text is in line with the specification of
    > the other bits in rfc7794.  No changes are needed.
    > 
    > If anything, you may want to change the order of this sentence to
    > address Ben's comment:
    > 
    > OLD>
    >     When a router propagates a prefix between ISIS levels ([RFC5302], it
    >     MUST preserve the ELC signaling for this prefix.
    > 
    > NEW>
    >     The ELC signaling MUST be preserved when a router propagates a prefix
    >     between ISIS levels ([RFC5302]).
    > 
    > [Similar for OSPF.]

    ##PP
    done.


    > 
    > 
    > 
    > I think that for OSPF it is not that simple...
    > 
    > For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix
    > Opaque LSA depends on the scope of the advertised prefixes", which I
    > assume means that for intra-area prefixes the scope will be
    > area-local...so the ABR wouldn't simply propagate it; it would have to
    > originate a new LSA.

    ##PP
    correct. It is always a new LSA that ABR needs to generate. Here it's 
    actually two LSAs.

    > 
    > Suggestion (Add to 3.1)>
    >     When an OSPFv2 Area Border Router (ABR) distributes information between
    >     connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA
    >     [RFC7684] including the received ELC setting.  If the received information
    >     is included in an LSA with an AS-wide scope, then the new LSA is not needed.

    Here's my suggestion for OSPFv2 ABR related text:

    "The ELC signaling MUST be preserved when an OSPF Area Border Router 
    (ABR) distributes information between connected areas. To do so, ABR 
    MUST originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including 
    the received ELC setting."

Ok - I change "connected areas" to "areas" and "ABR MUST" to "an ABR MUST". 

    Here's my suggested text for OSPFv2 ASBR case:

    "When an OSPF Autonomous System Boundary Router (ASBR) redistributes a 
    prefix from another instance of OSPF or from some other protocol, it 
    SHOULD preserve the ELC signaling for the prefix if it exists. To do so, 
    ASBR SHOULD originate Extended Prefix Opaque LSA [RFC7684] including the 
    ELC setting of the redistributed prefix. The flooding scope of the 
    Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that 
    ASBR originates as a result of the redistribution. The exact mechanism 
    used to exchange ELC between protocol instances on the ASBR is outside
    of the scope of this document."

Sure - replace "ASBR SHOULD" with "an ASBR SHOULD", "that ASBR" with "that an ASBR", and "the ASBR is" with "an ASBR is" to be consistent. 
Also, "originate Extended" with "originate an Extended". 



    > 
    > 
    > For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find
    > anything in rfc5340 saying that the received values should be copied
    > into the Inter-Area-Prefix-LSA (nor that they should not).
    > 
    > Suggestion (Add to 3.2)>
    >     When an OSPFv3 Area Border Router (ABR) distributes information between
    >     connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA
    >     MUST be the same as the received value.

    Here's my suggestion for OSPFv3 ABR and ASBR:

    "The ELC signaling MUST be preserved when an OSPFv3 Area Border Router 
    (ABR) distributes information between connected areas. The setting of 
    the ELC Flag in the Inter-Area-Prefix-LSA [RFC5340] or in the 
    Inter-Area-Prefix TLV [RFC8362], generated by ABR, MUST be the same as 
    the value the ELC Flag associated with the prefix in the source area."

Same change - replace "connected areas" with "areas" and "by ABR" with "by an ABR". 

    "When an OSPFv3 Autonomous System Boundary Router (ASBR) redistributes a 
    prefix from another instance of OSPFv3 or from some other protocol, it 
    SHOULD preserve the ELC signaling for the prefix if it exists. The 
    setting of the ELC Flag in the AS-External-LSA [RFC5340] or in the 
    External-Prefix TLV [RFC8362], generated by ASBR, MUST be the same as 
    the value the ELC Flag associated with the prefix in the source domain.	 
    The exact mechanism used to exchange ELC between protocol instances on 
    the ASBR is outside of the scope of this document. 

Add "NSSA-LSA" as a case. Replace "by ASBR" with "by an ASBR" and "value the ELC" with "value of the ELC". 

Thanks,
Acee

    thanks,
    Peter


    > 
    > 
    > 
    > 
    >>> (2) If the propagation is not automatic, and the L1L2 router doesn't
    >>> support this specification, then what are the drawbacks/failure
    >>> scenarios? IOW, for multi-level operation is it a requirement that
    >>> the L1L2 support this specification?
    >>
    >> drawback are identical to what is mentioned in the Security
    >> Considerations section.
    > 
    > I think that text is ok.
    > 
    > 
    > Thanks!
    > 
    > Alvaro.
    > 
    >