Re: [Bier] Alvaro Retana's No Objection on draft-ietf-bier-ospf-bier-extensions-14: (with COMMENT)

[Alia Atlas <[e-mail]>]

Hi Peter,

I do not see discussion with Eric or Suresh on their Discusses.
This draft also has Normative References to RFC 8279 and RFC 8296.

The Discusses need to be resolved.  The normative reference (where the
Status Update
was deferred), means that when this is approved, it'll have to have an RFC
Editor Note to
hold it until that Status Update is approved (or bis versions are issued,
if necessary).

I do not know if resolving of the Discusses will happen by Weds of IETF.
If not, then the
draft will not have a Yes ballot (unless Alvaro changes his) and may need
to go back through
IESG Evaluation.

Regards,
Alia

On Tue, Mar 6, 2018 at 5:17 PM, Tony Przygienda <[e-mail]> wrote:

> OK,
>
> draft-ietf-bier-isis-extensions-09
> <https://datatracker.ietf.org/doc/draft-ietf-bier-isis-extensions/>
>
>
> limited last call finished now. I see the document moved to publication.
>
> On OSPF I still see Suresh & Eric in discuss. Peter, did we address those
> comments ?
>
> thanks
>
> --- tony
>
>
>
> On Thu, Mar 1, 2018 at 7:57 PM, Tony Przygienda <[e-mail]>
> wrote:
>
>> ok, I went over it once more, all issues seem addressed adequatly.
>> Outstanding points I don't think need addressing further
>>
>> * invalid vs. illegal BFR-id language disparity ospf vs isis signalling.
>> That's really a defect of RFC8279 where we should have been stricter with
>> language. Not a problem of IGP drafts
>> * registry: I think that will be cleaned up during publication process,
>> i.e. registry created and references taken out of the drafts
>> * no /32 /128 length restriction in OSPF which IMO is fine given RFC8279
>> is not mandating it and OSPF works fine without this restriction. The
>> length clause would not change any other considerations anyway such as
>> behavior when 2 routers advertise the same prefix in an area with
>> conflicting BIER information which is addressed in the draft already.
>>
>> Alvaro, I issue here a 7 days last WG LC just to have it all following
>> procedure the way ISIS draft did and then fwd' back to IESG for publication
>> ...
>>
>> Everyone, this constitutes a 7 days last call limited to changes in
>> versions -14 and -15
>>
>> thanks
>>
>> --- tony
>>
>> On Fri, Feb 23, 2018 at 6:58 AM, Alvaro Retana <[e-mail]>
>> wrote:
>>
>>> Peter:
>>>
>>> Hi!  Thanks for addressing my comment!
>>>
>>> Alvaro.
>>>
>>> On February 23, 2018 at 8:16:49 AM, Peter Psenak ([e-mail])
>>> wrote:
>>>
>>> Hi Alvaro,
>>>
>>> please see inline (##PP):
>>>
>>> On 23/02/18 00:14 , Alvaro Retana wrote:
>>> > On February 22, 2018 at 11:57:08 AM, Peter Psenak ([e-mail]
>>> > <mailto:[e-mail]>) wrote:
>>> >
>>> > Peter:
>>> >
>>> > Hi!
>>> >
>>> >> > ----------------------------------------------------------------------
>>>
>>> >> > COMMENT:
>>> >> > ----------------------------------------------------------------------
>>>
>>> >> >
>>> >> > (1) The specification of the sub-TLVs still needs some work:
>>> >> >
>>> >> > - MT-ID: What should a receiver do if the MT-ID is in the 128-255
>>> range?
>>> >>
>>> >> rfc4915 says these are "Invalid and SHOULD be ignored" Do we nee to
>>> say
>>> >> the same here again?
>>> >
>>> > Yes. rfc4915 refers specifically to what to do with the value in the
>>> > LSAs when used for MTR.
>>> >
>>> > What does it mean to ignore the MT-ID in the BIER Sub-TLV?
>>> >
>>> > For example... "Each BFR sub-domain MUST be associated with one and
>>> only
>>> > one OSPF topology that is identified by the MT-ID." If the MT-ID is
>>> not
>>> > known (because it is ignored), then how can we enforce this check?
>>>
>>> ##PP
>>> ok, I have added the following statement:
>>>
>>> "If the MT-ID value is outside of the values specified in [RFC4915], the
>>> BIER Sub-TLV MUST be ignored."
>>>
>>> >
>>> >
>>> >> >
>>> >> > - "BFR-id...If the BFR is not locally configured with a valid
>>> BFR-id, the value
>>> >> > of this field is set to invalid BFR-id per [RFC8279]." I looked in
>>> rfc8279 for
>>> >> > the text about "invalid BFR-id", but found this instead: "The value
>>> 0 is not a
>>> >> > legal BFR-id." I assume that in this case "invalid" is the same as
>>> "not
>>> >> > legal". It would be nice to be consistent.
>>> >>
>>> >> would you agree with:
>>> >>
>>> >> "the value of this field is set to 0, which is defined as illegal in
>>> >> [RFC8279].
>>> >
>>> > Yeah, that’s fine.
>>> >
>>> > Side comment: it’s a shame that rfc8279 chose “illegal” to describe a
>>> > value that can be used.
>>> >
>>> >
>>> >> >
>>> >> > - "When such duplication is detected all BFRs advertising
>>> duplicates MUST be
>>> >> > treated as if they did not advertise a valid BFR-id." How are BFRs
>>> that
>>> >> > advertise an invalid BFR-id treated?
>>> >>
>>> >> what about:
>>> >>
>>> >> "as if they did not advertise a legal BFR-id"
>>> >
>>> > Sorry…the question is: if the BFD-id is 0, then what? What needs to be
>>> > done by the receiver?
>>>
>>> rfc8279, section 5 says:
>>>
>>> " If BFR-A determines that BFR-B and BFR-C have both advertised the
>>> same BFR-id for the same sub-domain, BFR-A MUST log an error.
>>> Suppose that the duplicate BFR-id is "N". When BFR-A is
>>> functioning as a BFIR, it MUST NOT encode the BFR-id value N in
>>> the BIER encapsulation of any packet that has been assigned to the
>>> given sub-domain, even if it has determined that the packet needs
>>> to be received by BFR-B and/or BFR-C.
>>>
>>> This will mean that BFR-B and BFR-C cannot receive multicast
>>> traffic at all in the given sub-domain until the provisioning
>>> error is fixed. However, that is preferable to having them
>>> receive each other's traffic.
>>>
>>>
>>> ...
>>>
>>> If a BFR advertises that it has a BFR-id of 0 in a particular
>>> sub-domain, other BFRs receiving the advertisement MUST interpret
>>> that advertisement as meaning that the advertising BFR does not have
>>> a BFR-id in that sub-domain."
>>>
>>>
>>> So I rewrote the section as:
>>>
>>> "All BFRs MUST detect advertisement of duplicate valid BFR-IDs for a
>>> given MT-ID and Sub-domain-ID. When such duplication is detected by the
>>> BFR, it MUST behave as described in section 5 of [RFC8279]."
>>>
>>>
>>> >
>>> >
>>> >> >
>>> >> > - What should a receiver do if the BSL is set to a value not
>>> supported in
>>> >> > rfc8296?
>>> >>
>>> >> what about:
>>> >>
>>> >> "If the BS length is set to a value that does not match any of the
>>> >> allowed values specified in [RFC8296], the BIER MPLS Encapsulation
>>> >> Sub-TLV MUST be ignored."
>>> >
>>> > ok
>>> >
>>> >
>>> >> >
>>> >> > - "Label ranges within all BIER MPLS Encapsulation Sub-TLVs
>>> advertised by the
>>> >> > same BFR MUST NOT overlap. If the overlap is detected, the
>>> advertising router
>>> >> > MUST be treated as if it did not advertise any BIER sub-TLVs." If
>>> an overlap
>>> >> > is detected, the result is that *all* BFRs (advertising the
>>> overlap) are
>>> >> > treated as if the BIER sub-TLV was not advertised, right? The text
>>> is not
>>> >> > clear as to whether the result applies to all or just the BFR that
>>> advertised
>>> >> > last (and resulted in the detection happening).
>>> >>
>>> >> above paragraph talks about the case where a single BFR advertises
>>> the
>>> >> overlapping label ranges in multiple BIER MPLS Encapsulation Sub-TLVs
>>> it
>>> >> advertises.
>>> >
>>> > Yeah…sorry…overlooked that first part.
>>> >
>>> >
>>> >> >
>>> >> > - "All advertised labels MUST be valid..." What is a "valid" label?
>>> >>
>>> >> I'm tempted to get rid of the above statement, as we specified
>>> earlier
>>> >> that the label "A 3 octet field, where the 20 rightmost bits
>>> represent
>>> >> the first label" and any value should be fine.
>>> >
>>> > Well…there are some reserved values… rfc3032…
>>> >
>>>
>>> How to deal with the reserved labels by BIER should have been defined in
>>> rfc8296 or rfc8279, not in the IGP extension draft really. I have
>>> removed the following text:
>>>
>>> "All advertised labels MUST be valid, otherwise the BIER sub-TLV MUST be
>>> ignored.
>>>
>>> thanks,
>>> Peter
>>>
>>> >
>>> > ...
>>> >
>>> >> >
>>> >> > (2) Security Considerations
>>> >> >
>>> >> > - I support Eric's DISCUSS. It seems to me that an attacker could
>>> simply
>>> >> > advertise duplicate BFR-IDs or overlapping label ranges and have a
>>> significant
>>> >> > impact on the network.
>>> >>
>>> >> that should be taken care of by protocol authentication and existing
>>> >> text covers that:
>>> >>
>>> >> "There can be deployments where potential attackers have access to
>>> one
>>> >> or more networks in the OSPF routing domain. In these deployments,
>>> >> stronger authentication mechanisms such as those specified in
>>> [RFC7474]
>>> >> SHOULD be used."
>>> >
>>> > I’ll let Eric handle the DISCUSS and whether he thinks this is ok.
>>> >
>>> >> >
>>> >> > (3) IANA Considerations
>>> >> >
>>> >> > Section 2.2: "The BIER MPLS Encapsulation Sub-TLV is a Sub-TLV of
>>> the BIER
>>> >> > Sub-TLV." However, the type for this sub-sub-TLV is allocated from
>>> the OSPF
>>> >> > Extended Prefix sub-TLV registry...and not from a new registry for
>>> sub-TLVs for
>>> >> > the BIER Sub-TLV.
>>> >>
>>> >> The OSPFv2 Extended Prefix TLV Sub-TLVs registry "defines sub-TLVs
>>> >> at any level of nesting for OSPFv2 Extended Prefix TLVs".
>>> >>
>>> >> We have 16 bits for TLV type in OSPF, so we can afford to do so :)
>>> >
>>> > Ah, I see. That text is buried in rfc7684, and not reflected in the
>>> > registry itself.
>>> >
>>> > We’re good then.
>>> >
>>> > Thanks!
>>> >
>>> > Alvaro.
>>> >
>>>
>>>
>>> _______________________________________________
>>> BIER mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/bier
>>>
>>>
>>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>
>