Re: [OSPF] Working Group Last Call for OSPFv2 Segment Routing - draft-ietf-ospf-segment-routing-extensions-17

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

The WG last call on the -17 updates to the document has concluded without
substantive comment.

Thanks,
Acee 

On 6/23/17, 2:07 PM, "OSPF on behalf of Acee Lindem (acee)"
<[e-mail] on behalf of [e-mail]> wrote:

>Since an unimplemented section was removed and there were also a number of
>clarifications, I’d like to request a WG last call on the modified draft.
>It will end on July 1st, 2017 at 12:00 AM GMT. For your convenience, here
>are the relevant links.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extension
>s
>/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-17
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-exte
>n
>sions-17
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-extensio
>n
>s-17
>
>Thanks,
>Acee 
>
>
>
>
>On 6/23/17, 6:14 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
><[e-mail] on behalf of [e-mail]> wrote:
>
>>Hi Alia,
>>
>>thanks for comments, please see inline:
>>
>>
>>On 31/05/17 04:05 , Alia Atlas wrote:
>>> As is customary, I have done my AD review
>>> of draft-ietf-ospf-segment-routing-extensions-16 once publication has
>>> been requested.  First, I would like to thank the editors & many
>>> authors, Peter, Stefano, Clarence, Hannes, Rob, Wim & Jeff, for the
>>>work
>>> that they have put in so far and the remaining work that is greatly
>>>needed.
>>>
>>> While there are a great many issues to be handled, they fall primarily
>>> into three categories.  The first is simply not going through and
>>> tightening up the details; for example, stating that the length of a
>>>TLV
>>> is variable provides no meaning.  The second is that the technical
>>> documents from SPRING that this draft depends on do not adequately
>>> describe the use of the advertised information (SID/Label Binding TLV)
>>> or some of the concepts (e.g. SR Mapping Server).  The third is a more
>>> common set of handling error cases and adding clarity to the intended
>>> behavior.  I do not see issues with the encodings but I do see
>>>fragility
>>> with the unstated assumptions and behaviors.  The draft describes
>>> encodings, but very little of the handling, behaviors, or meaning - and
>>> the references do not provide adequate detail.
>>>
>>> I have spent all day (and evening) doing this review and I am quite
>>> disappointed and concerned about the document.  I would strongly
>>> recommend having sharing the next WGLC with the SPRING working group;
>>> perhaps more eyes will help with the discrepancies.
>>>
>>> I have not yet decided what to do about the "early" IANA allocation -
>>> which has now existed for this draft for 3 years.  I do know that there
>>> are implementations,
>>> but I am currently seeing the failure of this work to successfully
>>> complete as an example of an issue with providing early allocations.
>>>
>>> MAJOR ISSUES:
>>>
>>> 1) This draft has 7 authors.  The limit for authors & editors is 5, as
>>> is clearly stated in RFC 7322 Sec 4.1.1 and has been the case for well
>>> over a decade, unless there are extraordinary circumstances.  Is there
>>>a
>>> reason to not simply list the active editor and move the others to
>>> contributors?  One of the authors is already listed there.  I regret
>>> that failure to deal earlier with this long-standing IETF policy will
>>>be
>>> delaying progressing the draft.
>>
>>I don't know how to resolve this. I can not tell any of the coauthors
>>that I'm going to drop him from the list after his contribution to this
>>for several years. Two of us are marked as editors already.
>>
>>
>>>
>>> 2) This expired individual
>>> draft(draft-minto-rsvp-lsp-egress-fast-protection-03) is listed as
>>> Informative - but IS ACTUALLY NORMATIVE since it DEFINES the
>>> "M-bit - When the bit is set, the binding represents a mirroring
>>>context
>>> as defined in [I-D.minto-rsvp-lsp-egress-fast-protection]."
>>>   Unfortunately, when I look there for the definition of a mirroring
>>> context, it doesn't exists.
>>
>>Section 6 was removed.
>>
>>
>>>
>>> 3) The following Informative references expired several years ago and -
>>> being individual drafts - do not appear to convey the SPRING or TEAS WG
>>> consensus.
>>>     a)  draft-filsfils-spring-segment-routing-ldp-interop-03 was
>>> replaced with draft-ietf-spring-segment-routing-ldp-interop-07 and
>>>there
>>> are considerable differences.
>>
>>fixed
>>
>>>     b) It is unclear what happened
>>> to draft-filsfils-spring-segment-routing-use-cases-01, but I do not see
>>> any successor - or reason for this individual draft to explain the
>>> OSPFv2 extensions more than work from the SPRING WG.
>>
>>I replaced it with RFC7855.
>>
>>>
>>> 4) Sec 3.3: Is it ok to advertise an SRLB TLV without advertising the
>>> SR-Algorithm TLV?  What is the expected behavior and assumptions by the
>>> receiver?
>>
>>These are independent TLVs. Both are optional and there is no dependency
>>between them.
>>
>>>
>>> 5) Sec 3.4:  What happens if an SRMS Preference TLV is advertised
>>> without an SR-Algorithm TLV in the same scope?
>>
>>SRMS Preference TLV is independent of the SR-Algorithm TLV.
>>
>>The fact that SRMS provides mapping between addresses and SIDs, does not
>>require SRMS to support SR at all. SRMS functionality can be run on a
>>node that is never in the data path and as such does not need to support
>>SR.
>>
>>
>>> I see that it says "For
>>> the purpose of the SRMS Preference Sub-TLV advertisement, AS scope
>>> flooding is required." but also provides for area scope flooding.  Some
>>> words clarifying the expected behavior would be useful.
>>
>>   "For the purpose of the SRMS
>>    Preference Sub-TLV advertisement, AS scope flooding is required."
>>
>>above refers to a generic case, where the SRMS can be located anywhere
>>in the network, which means it can be in a different area.
>>
>>
>>    "If
>>    the SRMS advertisements from the SRMS server are only used inside the
>>    area to which the SRMS server is attached, area scope flooding may be
>>    used."
>>
>>Above says that if the usage of the SRMS advertisements is bound to an
>>area, area flooding is sufficient.
>>
>>I added some more text to the first part above to make it clear that the
>>is referring to the multi-area case.
>>
>>
>>>
>>> 6) Sec 5: "In such case, MPLS EXP bits of the Prefix-SID are not
>>> preserved for
>>> the final destination (the Prefix-SID being removed)."   I am quite
>>> startled to see an assumption that MPLS Pipe mode is being forced as
>>> part of specifying PHP mode!  This will also break any ECN or 3-color
>>> marking that has affected the MPLS EXP bits.  I would like to see and
>>> understand a clear justification for why short-pipe mode is being
>>> required instead of Uniform (or up to implementation/configuration.).
>>> Basically, this sentence means that transport considerations are a
>>> necessary section - which is completely inappropriate in an IGP draft.
>>
>>sentence has been removed.
>>
>>>
>>> 7) Sec 6: This section defines the SID/Label Binding sub-TLV - which
>>> appears to be a way to advertise an explicit path - and has a SID/Label
>>> by which the path can be entered.   How and what state is set up by the
>>> sending router to create the indicated segment is completely unclear.
>>> I have hunted
>>> through draft-ietf-spring-segment-routing,
>>>draft-ietf-spring-segment-routing-mpls,
>>> and draft-ietf-spring-segment-routing-ldp-interop, RFC7855,
>>> and draft-ietf-isis-segment-routing-extensions.   As far as I can tell,
>>> NONE of them clearly describe the details of where and why this
>>> advertising is needed.  Obviously, this mechanism does allow the
>>> potential shortening of the MPLS label stack at the cost of advertising
>>> multi-hop explicit path segments across the entire area or AS.  There
>>> MUST be a normative description of what the sending router will do when
>>> a packet is received with the specified label.
>>
>>section 6 has been removed.
>>
>>>
>>> 8) Sec 4: "The Segment Routing Mapping Server, which is described in
>>> [I-D.filsfils-spring-segment-routing-ldp-interop]"  Where precisely is
>>> an SRMS and its behavior/role actually defined?
>>>   draft-ietf-spring-segment-routing-ldp-interop-07 claims:"SR to LDP
>>> interworking requires a SRMS as defined in
>>> [I-D.ietf-isis-segment-routing-extensions]." but that wouldn't be
>>> appropriate, of course, and it isn't there either!
>>>   draft-ietf-spring-conflict-resolution-04 talks about SRMS, but
>>>doesn't
>>> define it.   draft-ietf-spring-segment-routing-11 mentions in Sec 3.5.1
>>> that "A Remote-Binding SID S advertised by the mapping server M" and
>>> refers to the ldp-interop draft for further details - but obviously not
>>> about an SRMS.
>>
>>
>>A new text has been added to filsfils-spring-segment-routing-ldp-interop
>>to explain the SRMS better.
>>
>>>
>>> Minor Issues:
>>>
>>> 1) In Sec 3.1, it says: "The SR-Algorithm TLV is optional. It MUST only
>>> be advertised once in the Router Information Opaque LSA.If the
>>> SID/Label Range TLV, as defined in Section 3.2, is advertised, then the
>>> SR-Algorithm TLV MUST
>>
>>I removed the above sentence, it is not required. Following sentence in
>>the draft clearly says:
>>
>>"If the SR-Algorithm TLV is not advertised by the node, such node is
>>considered as not being segment routing capable."
>>
>>> also be advertised."  Please provide a pointer in the text to the
>>> behavior for a receiving router if one or both of these are violated?
>>> For the requirement to advertise the SR-Algorithm TLV, please clarify
>>> that this is in the same RI LSA as the SID/Label Range TLV was
>>> advertised & with the same scope.  What does it mean, in terms of the
>>> receiving router, to determine that the sending router supports SR or
>>> not - given the possibility of receiving other SR-related TLVS in an RI
>>> LSA without getting an SR-Algorithm TLV?
>>
>>please see above.
>>
>>>
>>> 2) Sec 3.1: The SR-Algorithm TLV simply defines "Length: Variable".
>>> Given that advertising Algorithm 0 is required, I'm fairly sure that
>>>the
>>> Length has to be a minimum of 1 - and, to prevent overrun & weird
>>> issues, let's have a reasonable maximum (for instance, 24) too.  It
>>> wouldn't hurt to remind readers that the length is just that of the
>>> value field - though experienced OSPF implementers will know that.
>>
>>I added "dependent on number of Algorithms advertised".
>>
>>But I'm not sure why would we want to limit ourselves to 24 or any
>>specific length.
>>
>>>
>>> 3) Sec 3.1 & Sec 3.2 & Sec 3.3: "For the purpose of SR-Algorithm TLV
>>> advertisement, area scope flooding is required." and "For the purpose
>>>of
>>> SID/Label Range TLV advertisement, area scope flooding is required."
>>>   and "For the purpose of SR Local Block Sub-TLV TLV advertisement,
>>>area
>>> scope flooding is required." Please capitalize REQUIRED as per RFC
>>> 2119.  Otherwise, please explain behavior when area scope isn't used.
>>
>>I change to REQUIRED.
>>
>>I'm not sure why do we need to explain what happens if other scope is
>>used, when we say what is REQUIRED. If someone uses link scope,
>>information would not be propagated where it needs to be present. If
>>someone uses AS scope the information would go to places where it is not
>>needed. Do we need to say that explicitly in the draft? We used teh same
>>wording in other RFCs, without describing what happens if the REQUIRED
>>is not followed.
>>
>>
>>>
>>> 4) Sec 3.2:  The SID/Label Range TLV doesn't indicate that include a
>>> SID/Label sub-TLV is required - but I don't understand how it could be
>>> interpreted otherwise; nor does it indicate what to do if there are
>>> multiple SID/Label sub-TLVs included in a single SID/Label Range TLV.
>>
>>added text that the SID/Label sub-TLV MUST be included
>>
>>I also added some text about handling of multiple SID/Label TLVs.
>>
>>
>>
>>> Again "Length" is just defined as variable.  In this case, it clearly
>>> can't be less than 11 (probably 12, assuming padding to the 32-bit
>>> boundary).   It would be useful to have an upper-bound on length, but
>>>at
>>> least here I can see the argument that meaningful flexibility is
>>> provided for.
>>
>>I added "dependent on sub-TLVs.", which we used in rfc7684
>>
>>>
>>> 5) SID index is used without introduction in Sec 3.2.  It isn't defined
>>> in the terminology of draft-ietf-spring-segment-routing-11 and the
>>>other
>>> uses of it in this document aren't enough to clearly define it.  Please
>>> add at least a description of its meaning before use - in a terminology
>>> section, if necessary.
>>
>>Added some text at the beginning of section 3.2.
>>
>>>
>>> 6) Sec 3.2: "The originating router advertises the following ranges:
>>>           Range 1: [100, 199]
>>>           Range 2: [1000, 1099]
>>>           Range 3: [500, 599]"
>>> Please turn this into the information actually advertised - i.e.
>>>     Range 1: Range Size: 100   SID/Label sub-TLV: 100  => meaning [100,
>>>199]
>>> etc.
>>
>>fixed.
>>
>>
>>>
>>> 7) 3.2. SID/Label Range TLV:  Please specify that the sender MUST NOT
>>> advertise overlapping ranges & how to handle the case when it does.
>>> This is required by draft-ietf-spring-conflict-resolution.
>>
>>done.
>>
>>>
>>> 8) Sec 3.3  SR Local Block (SRLB) Sub-TLV: The document doesn't specify
>>> that the SR Local Block TLV MUST include a SID/Label sub-TLV nor
>>> indicate what to do if multiple are included.
>>
>>added text that the SID/Label sub-TLV MUST be included
>>
>>I also added some text about multiple SID/Label TLVs being present.
>>
>>> The Length, again, isn't
>>> specified at all and clearly has at least a minimum.
>>
>>I added "dependent on sub-TLVs.", which we used in rfc7684
>>
>>
>>> I don't see a
>>> reference to an SR Local Block or the need to advertise it
>>> in draft-ietf-spring-segment-routing-11; perhaps I missed where the
>>> requirement and usage are defined?
>>
>>The need for advertisement is described in latest version of
>>draft-ietf-spring-segment-routing-mpls.
>>
>>I also modified the text in OSPF draft to better describe the need for
>>advertisemement.
>>
>>
>>>
>>> 9) Sec 3.3: "Each time a SID from the SRLB is allocated, it SHOULD also
>>>be
>>>     reported to all components..."  Presumably, this is subjected to
>>>the
>>> normal OSPF dampening - it'd be nice to note that somewhere - since
>>> rapid sequential allocation may not provide the reporting speed
>>>anticipated.
>>
>>
>>SRLB is something that is either configured or eventually tight to a
>>platform. In neither case, this is not expected to change frequently.
>>
>>>
>>> 10) Sec 4: "AF: Address family for the prefix. Currently, the only
>>>supported
>>>        value is 0 for IPv4 unicast.  The inclusion of address family in
>>>        this TLV allows for future extension."  Could you please clarify
>>> if this is to reuse the same TLV for OSPFv3 so IPv6 can be supported,
>>> are you thinking of extending OSPFv2 for IPv6 prefixes for some cases
>>>or
>>> something else?
>>> I think the current phrasing is likely to raise
>>> questions.
>>
>>This mirrors what we have done for OSPFv2 Extended Prefix TLV in RFC768.
>>We defined these top level containers in a way that they are extendible
>>for other AFs.
>>
>>
>>> Similarly, please define "Prefix length: Length of the
>>> prefix" clearly.
>>
>>changed to "Length of prefix in bits." to mirror RFC768.
>>
>>> I really don't understand what the benefit of having a
>>> TLV that pretends to support multiple AFs but can't is versus the
>>> clarity of specifying the prefix lengths.
>>
>>I fixed the Address Prefix encoding text to mirror RFC7684.
>>
>>>
>>> 11) Sec 4:  Again "Length: Variable" - It should have a minimum and
>>> preferable describe a function for how it is computed.  A maximum is
>>> probably unlikely  with sub-TLVs.
>>
>>I added "dependent on sub-TLVs.", which we used in rfc7684
>>
>>
>>>
>>> 12) Sec 4: OSPF Extended Prefix Range TLV:  Does this TLV has any
>>> meaning or action associated with it without including sub-TLVs?
>>
>>no.
>>
>>> Are
>>> there mandatory sub-TLVs?  What is a receiving router to do with it?
>>
>>no. If it's empty, router just stores it in LSDB and do not use it for
>>anything.
>>
>>>
>>> 13) Sec 5: "If multiple Prefix-SIDs are advertised for the same prefix,
>>>the
>>>    receiving router MUST use the first encoded SID and MAY use
>>>    subsequent SIDs."  What does this even mean?  A receiving router
>>>when
>>> making the decision to use a subsequent SID is making a decision to not
>>> use the first encoded SID; it's not like the router is going to stick
>>> both SID/Labels onto the stack.   Please describe this in meaningful
>>> normative terms.
>>
>>replaced that text with a new one.
>>
>>>
>>> 14) Sec 5:" When calculating the outgoing label for the prefix, the
>>> router MUST
>>>     take into account the E and P flags advertised by the next-hop
>>>router
>>>     if that router advertised the SID for the prefix.  This MUST be
>>>done
>>>     regardless of whether the next-hop router contributes to the best
>>>     path to the prefix."  First, I assume this is "NP flag" because
>>> there is no P flag.
>>
>>corrected
>>
>>>     Second - please clarify to "take into account, as described below,
>>> the E and NP flags...".
>>
>>done
>>
>>
>>
>> >Third, the M flag must also be taken into
>>> account - given the text later in the section.
>>
>>corrected
>>
>>>
>>> 15) Sec 5: "When a Prefix-SID is advertised in an Extended Prefix Range
>>> TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted
>>>as a
>>>     starting SID value."   This appears to contradict "SID/Index/Label:
>>> According to the V and L flags, it contains either:
>>>
>>>           A 32-bit index defining the offset in the SID/Label space
>>>           advertised by this router.
>>>
>>>           A 24-bit label where the 20 rightmost bits are used for
>>>           encoding the label value."
>>
>>I added changed the text to:
>>
>>"Prefix SID Sub-TLV is interpreted as a starting SID/Label value", which
>>I believe should be sufficient.
>>
>>>    I assume that what is meant by the first quote is "...is
>>>interpreted,
>>> if the V flag is clear, as a starting SID value, and if the V flag is
>>> set, as a starting Label value."
>>> Otherwise, it looks like the
>>> Prefix-SID sub-TLV couldn't be included in the Extended Prefix Range
>>>TLV
>>> if a label value would be used.
>>> It would be helpful for Example 2 to show the label case.
>>>
>>> 16) Sec 6.1: "aggregate IGP or TE path cost."  Given that this is an
>>> OSPF draft, it'd be helpful to indicate whether there are challenges
>>> with non-comparable OSPF metrics (I'm thinking about AS-external type 2
>>> costs) or if the path will never include such costs.
>>
>>section 6 was removed
>>
>>>
>>> 17) Sec 6.2: "a domain and hence need to be disambiguated using a
>>> domain-unique Router-ID."  Given that the Prefix-SIDs and sub-TLVs can
>>> be distributed between areas and even redistributed between protocols,
>>> please clearly define what is meant by a "domain" or point to the
>>> appropriate definition.
>>
>>section 6 was removed
>>
>>
>>>
>>> 18) Sec 4, 5, 6:  Is it possible to have an OSPF Extended Prefix Range
>>> TLV that includes both a Prefix SID Sub-TLV and a SID/Label Binding
>>> Sub-TLV?   What does that mean?
>>
>>SID/Label Binding TLV was removed.
>>
>>>
>>> What does it mean if there are multiple prefixes described in the OSPF
>>> Extended Prefix Range TLV that includes a SID/Label Binding Sub-TLV?
>>> Does the SID/Label sub-sub-TLV indicate a single SID Index or Label
>>>that
>>> is used for the single path to all those prefixes?  Is it the start of
>>>a
>>> list of SID Indices or Labels?
>>> I see that the SID/Label Binding sub-TLV can be in both the OSPF
>>> Extended Prefx Range TLV as well as the OSPF Extended Prefix TLV - but
>>> there is no text on differences in interpretation.
>>
>>SID/Label Binding Sub-TLV was removed
>>
>>
>>>
>>> 19) Sec 7.1 & 7.2: Another  couple "Length: Variable."  Please actually
>>> specify the value. I think that, given the padding to 32-bit alignment,
>>> there is a single correct value.
>>
>>fixed.
>>
>>>
>>> 20) Sec 7.1 and 7.2: Given that the Flag bits have exactly the same
>>> meaning - it'd be clearer to have them defined once.
>>
>>done
>>
>>>
>>> 21) Sec 8.1: "An SR Mapping Server MUST use the OSPF Extended Prefix
>>> Range TLV when advertising SIDs for prefixes.  Prefixes of different
>>> route-types can be combined in a single OSPF Extended Prefix Range TLV
>>> advertised by an SR Mapping Server."    So - I can't find a normative
>>> definition of an SRMS to determine why it is always necessary to use an
>>> OSPF Extended Prefix Range TLV instead of an OSPF Extended Prefix TLV.
>>
>>for simplicity we only want to use OSPF Extended Prefix Range TLV when
>>advertising SRMS mapping entries. It's the encoding we enforced for SRMS
>>advertisement.
>>
>>> I don't see how advertising prefixes from different route-types can
>>>work
>>> unless the prefixes are adjacent, which seems likely to be uncommon.
>>> Perhaps what is meant is "Because the OSPF Extended Prefix Range TLV
>>> doesn't include a Route-Type field, as in the OSPF Extended Prefix TLV,
>>> it is possible to include adjacent prefixes from different Route-Types
>>> in the OSPF Extended Prefix Range TLV."
>>
>>yes, that is correct. I added the above text to the draft.
>>
>>>
>>> 22) Sec 8.1: "If multiple routers advertise a Prefix-SID for the same
>>> prefix, then
>>> the Prefix-SID MUST be the same.  This is required in order to allow
>>> traffic load-balancing when multiple equal cost paths to the
>>>destination
>>> exist in the OSPFv2 routing domain."  How is this enforced?  What are
>>> the consequences of it not being conformed to?  This is NOT a protocol
>>> implementation requirement.  This should really be called out in a
>>> Manageability Considerations with warnings.
>>
>>I removed the above text.
>>
>>>
>>> 23) Sec 8.2:"If no Prefix-SID was advertised for the prefix in the
>>> source area
>>>        by the router that contributes to the best path to the prefix,
>>>the
>>>        originating ABR will use the Prefix-SID advertised by any other
>>>        router when propagating the Prefix-SID for the prefix to other
>>>        areas."  I believe that this depends on the assumption that if a
>>> Prefix-SID is advertised by any router, the Prefix-SID will be the
>>> same.  Please be explicit in this assumption, since the requirement on
>>> the network operator should be clear as well as the consequences of not
>>> conforming.
>>
>>above text says that the prefix SID may come from different router then
>>the one which is contributing to the best path, if the router that
>>contributes to the best path is not advertising the SID. No assumption
>>about multiple SIDs being the same is made.
>>
>>>
>>> 24) Sec 10:  The Implementation Status section should indicate that it
>>> is to be removed before publication as an RFC.   Also, the complete
>>> implementation part seems a bit dated - given the draft's technical
>>> changes in the last 2 years.
>>
>>I added a sentence about this section being removed before publication.
>>
>>>
>>>
>>> NITS:
>>>
>>> 1) Sec 2.1: s/"SID/Label TLV"/"SID/Label sub-TLV"
>>
>>fixed all of them
>>>
>>> 2) Sec 3.2:"Initially, the only supported Sub-TLV is the SID/Label TLV
>>> as defined
>>>     in Section 2.1.  The SID/Label advertised in the SID/Label TLV
>>>     represents the first SID/Label in the advertised range."
>>>     replace SID/Label TLV with SID/Label sub-TLV.
>>
>>done.
>>
>>>
>>> 3) Sec 3.3 & Sec 3.4: " The SR Local Block (SRLB) Sub-TLV is a
>>>top-level
>>> TLV of the Router Information Opaque LSA (defined in [RFC7770])."
>>> Please correct the descriptions (many) to SR Local Block (SRLB) Sub-TLV
>>> to SR Local Block SRLB TLV.   The same issue exists for "SRMS
>>>Preference
>>> Sub-TLV".
>>
>>I updated the text to use the expanded name first time and use
>>abbreviated name in other places.
>>
>>thanks,
>>Peter
>>
>>
>>>
>>> Regards,
>>> Alia
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>
>>_______________________________________________
>>OSPF mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ospf
>
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf