Re: [Gen-art] New Version Notification for draft-ietf-ospf-rfc4970bis-06.txt

[Romascanu, Dan (Dan)]

Thank you for addressing my comments in a fast and efficient manner. 

Regards,

Dan


> -Original Message-
> From: Acee Lindem (acee) [mailto:a...@cisco.com]
> Sent: Friday, October 09, 2015 4:04 AM
> To: OSPF WG List
> Cc: Romascanu, Dan (Dan)
> Subject: FW: New Version Notification for draft-ietf-ospf-rfc4970bis-06.txt
> 
> This version includes Dan Romascanu’s Gen-ART review commments.
> 
> Thanks,
> 
> Acee
> 
> 
> 
> On 10/8/15, 8:59 PM, "internet-dra...@ietf.org" 
> 
> wrote:
> 
> 
> 
> >
> 
> >A new version of I-D, draft-ietf-ospf-rfc4970bis-06.txt
> 
> >has been successfully submitted by Acee Lindem and posted to the
> 
> >IETF repository.
> 
> >
> 
> >Name:draft-ietf-ospf-rfc4970bis
> 
> >Revision:06
> 
> >Title:   Extensions to OSPF for Advertising Optional Router
> Capabilities
> 
> >Document date:   2015-10-08
> 
> >Group:   ospf
> 
> >Pages:   15
> 
> >URL:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: A-D issues

[Shraddha Hegde]

David,

Pls see inline...

-Original Message-
From: Black, David [mailto:david.bl...@emc.com] 
Sent: Thursday, October 08, 2015 11:21 PM
To: Shraddha Hegde ; Rob Shakir ; 
a...@cisco.com; bruno.decra...@orange.com; ops-...@ietf.org; General Area 
Review Team (gen-art@ietf.org) ; lizhen...@huawei.com
Cc: a...@cisco.com; o...@ietf.org; i...@ietf.org; Black, David 

Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: 
A-D issues

Shradda,

We're very close to done here, thanks for the updated text.

I have one more concern on information completeness vs. tag removal (I'll deal 
w/[1] and the new Operational Considerations text in a separate message):

The last paragraph in Section 3.2 of the proposed-for-07 text says:

   On the receiver, When there is a change in
   the node administrative tag TLV or removal/ addition of a TLV in any
   instance of the RI-LSA, implementations MUST take appropriate
   measures to update its state according to the changed set of tags.

In addition, this comment was made in email:

 A node cannot determine that it has all the complete and
current information at any point of time.  This is true for any link
state IGP protocol which floods the data for distribution.

My Concern: How does a receiver detect tag removal or change when it has to 
assume that its tag information may always be incomplete?

Specifically, how does a receiver determine that a tag (or an old tag prior to 
a change) is not in some portion of the information that has not been received 
(and hence that a tag removal or change has occurred)?

 The receiver detects tag removal or change based on its current set 
of RI LSAs that it has in the database.
  How to determine whether there is removal of a tag is 
implementation specific.

  1) One way  is to  store all the node tags originated 
by a node and when new LSA arrives re populate the
node tags and compare old andnew tags. That 
can give the details of whether a tag was
   removed or changes/added
 2) Another way is to compare the RI LSA and there is 
any change simply pass the new set of tags to the
  processing/computation . In this case if tag 
moves from one RI LSA to the other re-processing happens. 

Generally, multiple LSA changes are combined in one event before triggering the 
processing. So if tag moves from one RI LSA to the other
If (1) is implemented no processing related to tags would be necessary.

But, all of this is vendor implementation specific  and we need not suggest one 
or the other way (May be there is a third way as well)in standards.
It should be good enough to say If there is any change in tags , redo the tag 
processing  and that's what the current text says I believe.

Thanks,
--David

> -Original Message-
> From: Shraddha Hegde [mailto:shrad...@juniper.net]
> Sent: Thursday, October 08, 2015 8:03 AM
> To: Black, David; Rob Shakir; a...@cisco.com; bruno.decra...@orange.com; 
> ops- d...@ietf.org; General Area Review Team (gen-art@ietf.org); 
> lizhen...@huawei.com
> Cc: a...@cisco.com; o...@ietf.org; i...@ietf.org
> Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06:
> A-D issues
> 
> Thanks David for the follow-up.
> Pls find details below.
> 
> [...Snip to open comments...]
> 
> David> Please add that statement, specifically that a receiver may 
> David> have to ignore tags that do not match any local policies.
> 
> Updated as below.
> 
> "If a receiving node does not
> understand the tag value or does not have a local policy corresponding 
> to the tag, it ignores the specific tag and floods the RI LSA without 
> any change as defined in ."
> 
> 
> David> For the first requirement, I was expecting the "MUST" to apply 
> David> only to "independent identifier," i.e.:
> 
> Each tag MUST be treated as an independent identifier that MAY be
> used in policy to perform a policy action.
> 
>  OK. Updating the draft as suggested.
> 
> Each tag MUST be treated as an independent identifier that MAY be 
> used in policy to perform a policy action. Tags carried by the 
> administrative tag TLV SHOULD be used to indicate independent 
> characteristics of a node. The administrative tag list within the TLV 
> MUST be considered an unordered list. Whilst policies may be 
> implemented based on the presence of multiple tags (e.g., if tag A AND 
> tag B are present), they MUST NOT be reliant upon the order of the 
> tags (i.e., all policies should be considered commutative operations, 
> such that tag A preceding or following tag B does not change their 
> outcome).
> 
> --
> 
> --
> 
> David> The last sentence appears to still have a problem:  How does a 
> David> receiving node de

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: [1] Operational Considerations

[Shraddha Hegde]

David,


   Defining language for local policies is outside the scope of this
   document.  As in case of other policy applications, the pruning
   policies can cause the path to be completely removed from forwarding OLD
   plane, hence are less preferred than the preference policies.
NEW
   plane, and hence have the potential for more severe operational
   impact (e.g., node unreachability due to path removal) by comparison
   to preference policies that only affect path selection.

 That’s more clear. Thanks a lot, I have updated the text in -07

Beyond that, I thought I saw some agreement that Section 4.5 warrants some text 
editing to better reflect this pruning vs. preference distinction - did Bruno 
volunteer to draft that text?

 Bruno started working on section 4.5 yesterday. Lets hope we have 
the changes before deadline.

Thanks
Shraddha 


-Original Message-
From: Black, David [mailto:david.bl...@emc.com] 
Sent: Thursday, October 08, 2015 11:34 PM
To: bruno.decra...@orange.com; Shraddha Hegde 
Cc: a...@cisco.com; o...@ietf.org; i...@ietf.org; Rob Shakir ; 
a...@cisco.com; ops-...@ietf.org; General Area Review Team (gen-art@ietf.org) 
; lizhen...@huawei.com; Black, David 
Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: 
[1] Operational Considerations

The new Operational Considerations text that Shradda sent out looks good.

I'd like to make one small change to avoid overusing the concept of
preference/preferred:

   Defining language for local policies is outside the scope of this
   document.  As in case of other policy applications, the pruning
   policies can cause the path to be completely removed from forwarding OLD
   plane, hence are less preferred than the preference policies.
NEW
   plane, and hence have the potential for more severe operational
   impact (e.g., node unreachability due to path removal) by comparison
   to preference policies that only affect path selection.

Beyond that, I thought I saw some agreement that Section 4.5 warrants some text 
editing to better reflect this pruning vs. preference distinction - did Bruno 
volunteer to draft that text?

Thanks,
--David

> -Original Message-
> From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
> Sent: Wednesday, October 07, 2015 5:48 AM
> To: Shraddha Hegde; Black, David
> Cc: a...@cisco.com; o...@ietf.org; i...@ietf.org; Rob Shakir; 
> a...@cisco.com; ops-...@ietf.org; General Area Review Team 
> (gen-art@ietf.org); lizhen...@huawei.com
> Subject: RE: Gen-ART and OPS-Dir review of 
> draft-ietf-ospf-node-admin-tag-06
> 
> Shraddha, David,
> 
> > From: Shraddha Hegde [mailto:shrad...@juniper.net] > Sent: 
> > Wednesday,
> October 07, 2015 9:08 AM
> 
> [...]
> 
> > -- 4.5.  Explicit routing policy
> >
> > In Figure 3:
> > - The link from the leftmost pair of A nodes to the pair of T nodes
> >do not have link weights.
> 
> [Bruno] There is some trade-off between adding more information on the 
> figure and its readability.
> Metrics value on links AT have no impact on routing assuming they have 
> the same value on both planes and that links in the lower/side of the 
> network are higher than link in the upper/core.
> The former is the case for links in the figure, and the latter is 
> rather typical in network, so I had assume that the metrics could be 
> removed in order to improve readability.
> But I agree that from the asci art, this is not that evident.
> Metric would be 10.
> Shraddha, you can either update the  figure or send me the latest xml 
> for update.
> 
> > - The link from the left R node to the left T node does not have a
> >link weight
> 
> [Bruno] Yes. Lack of space in the figure.
> Another option is to add a text to specific the metrics. e.g.
> 
> Proposed NEW:
> Links between T, R and I nodes have a metric of 100.
> Links between A nodes and R and T nodes have a metric of 10.
> Links between A nodes and I nodes have a metric of 201.
> 
> 
> Do you think this would be clearer?
> 
> > - The following example of an explicitly routed policy:
> >
> >   - Traffic from A nodes to I nodes must not go through R and T
> > nodes
> >
> > prevents the leftmost pair of A nodes from sending traffic to the
> > I nodes.  Was this "black hole" intended as part of the example?
> 
> [Bruno]
> In this specific example, the policy would be
> "  - Traffic from A nodes to A nodes should preferably go through R or T
> nodes (rather than through I nodes)
>   - Traffic from A nodes to I nodes must not go through R and T  nodes"
> 
> 
> Indeed, in the latter case, loss of connectivity (in case of double 
> independent failures) is preferred over using R or T nodes. (FYI in 
> this case, network would not have enough capacity to carry the traffic 
> in case of these double failures. It has been preferred to conceal the 
> impact of the failure to a limited network area, rather than impacting 
> another one. Trade-off again, but double ind

Re: [Gen-art] Gen-ART telechat review of draft-ietf-pwe3-iccp-stp-04

[Mingui Zhang]

Hi Brian, Andy,

Thanks for the suggestion!
I will add that description.

Mingui

> -Original Message-
> From: Andrew G. Malis [mailto:agma...@gmail.com]
> Sent: Thursday, October 01, 2015 8:35 AM
> To: Brian E Carpenter
> Cc: draft-ietf-pwe3-iccp-stp@ietf.org; General Area Review Team
> Subject: Re: Gen-ART telechat review of draft-ietf-pwe3-iccp-stp-04
> 
> Brian,
> 
> Thanks, I'll ask the authors to add that.
> 
> Cheers,
> Andy
> 
> On Wed, Sep 30, 2015 at 8:12 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
> 
> > Andy,
> >
> > I think most people think of a spanning tree as being constructed over
> > a set of bridges, so I guess that in addition to the sentences you
> > quote, I would be happy to see a more conceptual description in the
> Introduction
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-ospf-rfc4970bis-04

[Acee Lindem (acee)]

Hi Dan,

Thanks for the review - please see inline.

From: "Romascanu, Dan (Dan)" mailto:droma...@avaya.com>>
Date: Thursday, October 8, 2015 at 12:15 PM
To: General Area Review Team mailto:gen-art@ietf.org>>
Cc: 
"draft-ietf-ospf-rfc4970bis@tools.ietf.org"
 
mailto:draft-ietf-ospf-rfc4970bis@tools.ietf.org>>
Subject: Gen-ART review of draft-ietf-ospf-rfc4970bis-04
Resent-From: mailto:droma...@avaya.com>>
Resent-To: 
mailto:draft-ietf-ospf-rfc4970bis@ietf.org>>
Resent-Date: Thursday, October 8, 2015 at 12:16 PM


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-ospf-rfc4970bis-04

Reviewer: Dan Romascanu

Review Date: 10/8/15

IETF LC End Date: 10/8/15

IESG Telechat date: 10/15/15



Summary:

The document is ready with one issue for clarification and minor editorial 
observations.



Major issues:

None



Minor issues:



There seems to be an inconsistency between the way padding of the value fields 
in the value TLVs is defined in section 2.1, and in 2.3 and 2.5 respectively.



In 2.1 we have: ‘The padding is composed of zeros’



In 2.2 we have: ‘The format of the TLVs within the body of an RI LSA is defined 
as in Section 2.1’ This would include the V (value) field, thus the padding.



However, in 2.3 and 2.5 the definitions of the value fields stipulate they are 
‘padded with undefined bits’



Why this inconsistency?

This a good catch. I recently added the 'The padding is composed of zeros.' 
based on a comment. I should have made it ‘padded with undefined bits’ 
consistent was other text in RFC 4970. I’ll fix this.






Nits/editorial comments:



1.   If the TLV definitions within the body of the RI LSA are identical, it 
would have been better to separate this in a distinct sub-section.

Ok. I can do this.



2.   Please include a reference to the Vendor Enterprise Code in section 5.2

I will shorten this to “Enterprise Code” with a reference to RFC 5612. T

These changes are all in the -06 version.

Thanks,
Acee



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Call review of draft-blanchet-ccsds-urn-00

[Meral Shirazipour]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at < 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document: draft-blanchet-ccsds-urn-00
Reviewer: Meral Shirazipour
Review Date: 2015-10-08
IETF LC End Date:  2015-10-09
IESG Telechat date: 2015-10-15


Summary: This draft is ready to be published as Informational RFC.
Please refer to LC thread: 
http://www.ietf.org/mail-archive/web/gen-art/current/msg12267.html.

Major issues:
Minor issues:
Nits/editorial comments:


Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Assignments for the 2015-10-15 Telechat

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

ReviewerLC end   Draft
--
Alexey Melnikov 2015-04-08   draft-ietf-idr-ls-distribution-12 *

Brian Carpenter 2015-10-08   
draft-ietf-bess-mvpn-bidir-ingress-replication-03 **

Christer Holmberg   2015-09-22   draft-ietf-v6ops-siit-dc-02 **
Christer Holmberg   2015-09-22   draft-ietf-v6ops-siit-dc-2xlat-01 **
Christer Holmberg   2015-10-08   draft-ietf-bfd-rfc5884-clarifications-03

David Black 2015-10-08   draft-ietf-ospf-node-admin-tag-06

Dan Romascanu   2015-09-22   draft-ietf-v6ops-siit-eam-01 **
Dan Romascanu   2015-10-08   draft-ietf-ospf-rfc4970bis-05 *

Francis Dupont  2015-09-23   draft-kivinen-ipsecme-oob-pubkey-12 *
Francis Dupont  2015-10-13   draft-ietf-cdni-media-type-04 *

Meral Shirazipour   2015-10-09   draft-blanchet-ccsds-urn-00 **

Paul Kyzivat2015-09-30   draft-ietf-v6ops-pmtud-ecmp-problem-04 **

Roni Even   2015-09-10   draft-ietf-ippm-owamp-registry-03 *
Roni Even   2015-10-05   draft-ietf-trill-cmt-10 **

Russ Housley2015-10-02   draft-ietf-mpls-self-ping-05 *

Tom Taylor  2015-10-08   draft-ietf-tcpm-rtorestart-08

Vijay Gurbani   2015-09-15   draft-ietf-grow-bmp-15
Vijay Gurbani   2015-10-08   draft-ietf-ppsp-base-tracker-protocol-10


* Earlier draft reviewed
** Already reviewed


I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

For your convenience, the review boilerplate template is included below.

Note that reviews should ideally be posted to the gen-art mailing list
by COB on Tuesday:
http://wiki.tools.ietf.org/area/gen/trac/wiki/

Jean

---

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: [1] Operational Considerations

[Acee Lindem (acee)]

Hi Bruno, 

Did you see the action item below? It seems we are very close.

Thanks,
Acee

On 10/8/15, 2:03 PM, "Black, David"  wrote:

>The new Operational Considerations text that Shradda sent out looks good.
>
>I'd like to make one small change to avoid overusing the concept of
>preference/preferred:
>
>   Defining language for local policies is outside the scope of this
>   document.  As in case of other policy applications, the pruning
>   policies can cause the path to be completely removed from forwarding
>OLD
>   plane, hence are less preferred than the preference policies.
>NEW
>   plane, and hence have the potential for more severe operational
>   impact (e.g., node unreachability due to path removal) by comparison
>   to preference policies that only affect path selection.
>
>Beyond that, I thought I saw some agreement that Section 4.5 warrants
>some text editing to better reflect this pruning vs. preference
>distinction - did Bruno volunteer to draft that text?
>
>Thanks,
>--David
>
>> -Original Message-
>> From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
>> Sent: Wednesday, October 07, 2015 5:48 AM
>> To: Shraddha Hegde; Black, David
>> Cc: a...@cisco.com; o...@ietf.org; i...@ietf.org; Rob Shakir;
>>a...@cisco.com;
>> ops-...@ietf.org; General Area Review Team (gen-art@ietf.org);
>> lizhen...@huawei.com
>> Subject: RE: Gen-ART and OPS-Dir review of
>>draft-ietf-ospf-node-admin-tag-06
>> 
>> Shraddha, David,
>> 
>> > From: Shraddha Hegde [mailto:shrad...@juniper.net] > Sent: Wednesday,
>> October 07, 2015 9:08 AM
>> 
>> [...]
>> 
>> > -- 4.5.  Explicit routing policy
>> >
>> > In Figure 3:
>> > - The link from the leftmost pair of A nodes to the pair of T nodes
>> >do not have link weights.
>> 
>> [Bruno] There is some trade-off between adding more information on the
>>figure
>> and its readability.
>> Metrics value on links AT have no impact on routing assuming they have
>>the
>> same value on both planes and that links in the lower/side of the
>>network are
>> higher than link in the upper/core.
>> The former is the case for links in the figure, and the latter is rather
>> typical in network, so I had assume that the metrics could be removed
>>in order
>> to improve readability.
>> But I agree that from the asci art, this is not that evident.
>> Metric would be 10.
>> Shraddha, you can either update the  figure or send me the latest xml
>>for
>> update.
>> 
>> > - The link from the left R node to the left T node does not have a
>> >link weight
>> 
>> [Bruno] Yes. Lack of space in the figure.
>> Another option is to add a text to specific the metrics. e.g.
>> 
>> Proposed NEW:
>> Links between T, R and I nodes have a metric of 100.
>> Links between A nodes and R and T nodes have a metric of 10.
>> Links between A nodes and I nodes have a metric of 201.
>> 
>> 
>> Do you think this would be clearer?
>> 
>> > - The following example of an explicitly routed policy:
>> >
>> >   - Traffic from A nodes to I nodes must not go through R and T
>> >nodes
>> >
>> > prevents the leftmost pair of A nodes from sending traffic to the
>> > I nodes.  Was this "black hole" intended as part of the example?
>> 
>> [Bruno]
>> In this specific example, the policy would be
>> "  - Traffic from A nodes to A nodes should preferably go through R
>>or T
>> nodes (rather than through I nodes)
>>   - Traffic from A nodes to I nodes must not go through R and T
>>nodes"
>> 
>> 
>> Indeed, in the latter case, loss of connectivity (in case of double
>> independent failures) is preferred over using R or T nodes. (FYI in
>>this case,
>> network would not have enough capacity to carry the traffic in case of
>>these
>> double failures. It has been preferred to conceal the impact of the
>>failure to
>> a limited network area, rather than impacting another one. Trade-off
>>again,
>> but double independent failures have very low probability. In case of
>>such
>> "catastrophic"/hypothetic failure that the network is not capable of
>>handling,
>> experience shows that it's usually a good idea to try limiting the
>>scope of
>> the problem, rather than taking the risk to impact the whole network.
>>At least
>> until someone have a look at the problem and take a decision.)
>> We may change the text, if you want, in order to exactly refer to this
>> example. But this is just an example, and the one written in the
>>document is
>> equally valid.
>> 
>> 
>> > Also: "explicitly routed policies" -> "explicit routing policies"
>> 
>> [Bruno] yes, Thanks
>> 
>> 
>> >  It's probably not intended.
>> > Bruno, can you pls confirm?
>> 
>> [Bruno] Done.
>> 
>> 
>> > But, the example in itself is very much valid, with node admin tags
>> operators
>> > can
>> > have policies to drop traffic if destined towards certain prefixes.
>> > As Rob and Bruno, this is nothing new as such an operation is
>>possible today
>> > with routing policies.
>> 
>> -- Bruno
>> 
>> 
>> 
>>

[Gen-art] A *new* batch of IETF LC reviews - 2015-10-08

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer  LC end   Draft
-
Peter Yee 2015-10-15   draft-ietf-pals-ms-pw-protection-03

Ralph Droms   2015-10-19   draft-ietf-pals-mpls-tp-mac-wd-02

Robert Sparks 2015-10-19   draft-ietf-pals-redundancy-spe-02

Ron Bonica2015-10-19   draft-ietf-trill-rfc7180bis-05

Russ Housley  2015-10-19   draft-ietf-lisp-impact-04

Roni Even 2015-10-20 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-14

Suresh Krishnan   2015-10-21   draft-ietf-ippm-type-p-monitor-02

Tom Taylor2015-10-22   draft-ietf-ace-usecases-09


I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The /updated/ template is included below.

Thanks,

Jean

---

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: [1] Operational Considerations

[Black, David]

The new Operational Considerations text that Shradda sent out looks good.

I'd like to make one small change to avoid overusing the concept of
preference/preferred:

   Defining language for local policies is outside the scope of this
   document.  As in case of other policy applications, the pruning
   policies can cause the path to be completely removed from forwarding
OLD
   plane, hence are less preferred than the preference policies.
NEW
   plane, and hence have the potential for more severe operational
   impact (e.g., node unreachability due to path removal) by comparison
   to preference policies that only affect path selection.

Beyond that, I thought I saw some agreement that Section 4.5 warrants
some text editing to better reflect this pruning vs. preference
distinction - did Bruno volunteer to draft that text?

Thanks,
--David

> -Original Message-
> From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
> Sent: Wednesday, October 07, 2015 5:48 AM
> To: Shraddha Hegde; Black, David
> Cc: a...@cisco.com; o...@ietf.org; i...@ietf.org; Rob Shakir; a...@cisco.com;
> ops-...@ietf.org; General Area Review Team (gen-art@ietf.org);
> lizhen...@huawei.com
> Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06
> 
> Shraddha, David,
> 
> > From: Shraddha Hegde [mailto:shrad...@juniper.net] > Sent: Wednesday,
> October 07, 2015 9:08 AM
> 
> [...]
> 
> > -- 4.5.  Explicit routing policy
> >
> > In Figure 3:
> > - The link from the leftmost pair of A nodes to the pair of T nodes
> >do not have link weights.
> 
> [Bruno] There is some trade-off between adding more information on the figure
> and its readability.
> Metrics value on links AT have no impact on routing assuming they have the
> same value on both planes and that links in the lower/side of the network are
> higher than link in the upper/core.
> The former is the case for links in the figure, and the latter is rather
> typical in network, so I had assume that the metrics could be removed in order
> to improve readability.
> But I agree that from the asci art, this is not that evident.
> Metric would be 10.
> Shraddha, you can either update the  figure or send me the latest xml for
> update.
> 
> > - The link from the left R node to the left T node does not have a
> >link weight
> 
> [Bruno] Yes. Lack of space in the figure.
> Another option is to add a text to specific the metrics. e.g.
> 
> Proposed NEW:
> Links between T, R and I nodes have a metric of 100.
> Links between A nodes and R and T nodes have a metric of 10.
> Links between A nodes and I nodes have a metric of 201.
> 
> 
> Do you think this would be clearer?
> 
> > - The following example of an explicitly routed policy:
> >
> >   - Traffic from A nodes to I nodes must not go through R and T
> > nodes
> >
> > prevents the leftmost pair of A nodes from sending traffic to the
> > I nodes.  Was this "black hole" intended as part of the example?
> 
> [Bruno]
> In this specific example, the policy would be
> "  - Traffic from A nodes to A nodes should preferably go through R or T
> nodes (rather than through I nodes)
>   - Traffic from A nodes to I nodes must not go through R and T  nodes"
> 
> 
> Indeed, in the latter case, loss of connectivity (in case of double
> independent failures) is preferred over using R or T nodes. (FYI in this case,
> network would not have enough capacity to carry the traffic in case of these
> double failures. It has been preferred to conceal the impact of the failure to
> a limited network area, rather than impacting another one. Trade-off again,
> but double independent failures have very low probability. In case of such
> "catastrophic"/hypothetic failure that the network is not capable of handling,
> experience shows that it's usually a good idea to try limiting the scope of
> the problem, rather than taking the risk to impact the whole network. At least
> until someone have a look at the problem and take a decision.)
> We may change the text, if you want, in order to exactly refer to this
> example. But this is just an example, and the one written in the document is
> equally valid.
> 
> 
> > Also: "explicitly routed policies" -> "explicit routing policies"
> 
> [Bruno] yes, Thanks
> 
> 
> >  It's probably not intended.
> > Bruno, can you pls confirm?
> 
> [Bruno] Done.
> 
> 
> > But, the example in itself is very much valid, with node admin tags
> operators
> > can
> > have policies to drop traffic if destined towards certain prefixes.
> > As Rob and Bruno, this is nothing new as such an operation is possible today
> > with routing policies.
> 
> -- 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

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: A-D issues

[Black, David]

Shradda,

We're very close to done here, thanks for the updated text.

I have one more concern on information completeness vs. tag removal
(I'll deal w/[1] and the new Operational Considerations text in a
separate message):

The last paragraph in Section 3.2 of the proposed-for-07 text says:

   On the receiver, When there is a change in
   the node administrative tag TLV or removal/ addition of a TLV in any
   instance of the RI-LSA, implementations MUST take appropriate
   measures to update its state according to the changed set of tags.

In addition, this comment was made in email:

 A node cannot determine that it has all the complete and
current information at any point of time.  This is true for any link
state IGP protocol which floods the data for distribution.

My Concern: How does a receiver detect tag removal or change when it
has to assume that its tag information may always be incomplete?

Specifically, how does a receiver determine that a tag (or an old tag
prior to a change) is not in some portion of the information that has
not been received (and hence that a tag removal or change has occurred)?

Thanks,
--David

> -Original Message-
> From: Shraddha Hegde [mailto:shrad...@juniper.net]
> Sent: Thursday, October 08, 2015 8:03 AM
> To: Black, David; Rob Shakir; a...@cisco.com; bruno.decra...@orange.com; ops-
> d...@ietf.org; General Area Review Team (gen-art@ietf.org);
> lizhen...@huawei.com
> Cc: a...@cisco.com; o...@ietf.org; i...@ietf.org
> Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06:
> A-D issues
> 
> Thanks David for the follow-up.
> Pls find details below.
> 
> [...Snip to open comments...]
> 
> David> Please add that statement, specifically that a receiver may have
> David> to ignore tags that do not match any local policies.
> 
> Updated as below.
> 
> "If a receiving node does not
> understand the tag value or does not have a local policy corresponding to the
> tag,
> it ignores the specific tag and floods the RI LSA without any change as
> defined in ."
> 
> 
> David> For the first requirement, I was expecting the "MUST" to apply
> David> only to "independent identifier," i.e.:
> 
> Each tag MUST be treated as an independent identifier that MAY be
> used in policy to perform a policy action.
> 
>  OK. Updating the draft as suggested.
> 
> Each tag MUST be treated as an independent
> identifier that MAY be used in policy to perform a policy
> action. Tags carried by the administrative tag TLV SHOULD be used to indicate
> independent characteristics of a node. The administrative tag list within the
> TLV MUST be considered
> an unordered list. Whilst policies may be implemented based on the
> presence of multiple tags (e.g., if tag A AND tag B are present),
> they MUST NOT be reliant upon the order of the tags (i.e.,
> all policies should be considered commutative operations, such that
> tag A preceding or following tag B does not change their outcome).
> 
> --
> --
> 
> David> The last sentence appears to still have a problem:  How does a
> David> receiving node determine when it has a complete set of tags?  Suggested
> rephrase:
> 
>   When an RI LSA is received that changes the set of tags applicable to
>   any originating node, a receiving node MUST repeat any computation or
>   processing that is based on those administrative tags.
> 
> David> I think that captures the underlying point that processing MUST
> David> always be based on current tag information.
>   Updated as per suggestion
> 
>  Multiple node administrative tag TLVs MAY appear in an RI LSA or
>multiple node administrative tag TLVs MAY be contained in different
>instances of the RI LSA.  The node administrative tags associated
>with a node that originates tags for the purpose of any computation or
> processing at a receiving node
>SHOULD be a superset of node administrative tags from all the TLVs in all
> the
>received RI LSA instances originated by that node.When an RI LSA is
> received that changes the set of
>tags applicable to any originating node, a receiving node MUST repeat any
> computation or
>   processing that is based on those administrative tags.
> 
> --
> ---
> 
> David> I don't understand how a receiving node can be certain that a tag
> David> has been removed based on this sentence in Section 2:
> 
>Multiple TLVs MAY be added in same RI-LSA or in a different instance
>of the RI LSA as defined in [I-D.acee-ospf-rfc4970bis].
> 
> David> How does a receiving node determine that it has seen all the
> David> relevant RI LSAs and hence that absence of a previously seen tag
> David> renders that tag no longer applicable?  The "seen all the
> David> relevant RI 

Re: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

[Joel M. Halpern]

That would work very well for me.  Thank you for addressing my concerns.
Yours,
Joel

On 10/8/15 10:20 AM, Daniel Migault wrote:

Hi Joel,

Thank you for taking time to review and comment the draft.

We propose to add the following text to clarify the example in section 2 before 
the two last paragraphs. The following text expects to clarify the following 
points:
- 1) The creation of VPN is a local policy matter
- 2) Moving one duplicated VPN to different interfaces may involve multiple 
MOBIKE operations
- 4) There is no needs to create all possible VPNs ( might be similar to 
item 1)

The following text has been added to our local copy. If you would like us to 
publish a new version, feel free to let us know. Our intention is to keep the 
updates local until you ask us to publish the draft.

BR,
Daniel and Valery

NEW TEXT -- BEGIN
Note that it is up to host's local policy which additional VPNs to create and
when to do it. The process of selecting address pairs for migration is
  a local matter. Furthermore, in the case of multiple interfaces on
  both ends care should be taken to avoid the VPNs to be duplicated by both 
ends or moved to the both interfaces.

  In addition multiple MOBIKE operation may be involved from the
  Security Gateway or the VPN End User.
  Suppose, as depicted in Figure 3 for example that the cloned VPN is
  between Interface _0 and Interface_0', and the VPN End User and the
  Security Gateway wants to move it to Interface_1 and Interface_1'. The
  VPN End User may initiate a MOBIKE exchange in order to move it to
  Interface_1, in which case the cloned VPN is now between Interface_1
  and Interface_0'. Then the Security Gateway may also initiate a MOBIKE 
exchange in order to move the VPN to Interface_1' in which case the VPN has 
reached its final destination.
NEW TEXT -- END

-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Friday, October 02, 2015 1:25 PM
To: A. Jean Mahoney; General Area Review Team; 
draft-mglt-ipsecme-clone-ike-sa@ietf.org
Subject: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-mglt-ipsecme-clone-ike-sa-05.txt
Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)

Reviewer: Joel M. Halpern
Review Date: 2-Oct-2015
IETF LC End Date: 27-Oct-2015
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Propsoed Standard 
RFC.

Major issues:
  The introductory material talks about the case where both sides have 
multiple interfaces.  It is not clear what will happen with this mechanism in 
that case.
  In particular, if I have two systems, with three interfaces, it seems 
that this will start by creating the S1-D1 Security Association.
It seems straightforward for each side to create their simple additional 
assocations (S2-D1, S3-D1, and S1-D2, S1-D3).
  But the introduction suggests that we also want to create S2-D2, S3-D3, 
S2-D3, and S3-D2.  With no other guidance, it appears that both sides will try 
to create all four of those, creating 8 security associations instead of 4.
  I hope that I have simply missed something in the document that resolves 
this.

Minor issues:

Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-ospf-rfc4970bis-04

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-ospf-rfc4970bis-04

Reviewer: Dan Romascanu

Review Date: 10/8/15

IETF LC End Date: 10/8/15

IESG Telechat date: 10/15/15



Summary:

The document is ready with one issue for clarification and minor editorial 
observations.



Major issues:

None



Minor issues:



There seems to be an inconsistency between the way padding of the value fields 
in the value TLVs is defined in section 2.1, and in 2.3 and 2.5 respectively.



In 2.1 we have: 'The padding is composed of zeros'



In 2.2 we have: 'The format of the TLVs within the body of an RI LSA is defined 
as in Section 2.1' This would include the V (value) field, thus the padding.



However, in 2.3 and 2.5 the definitions of the value fields stipulate they are 
'padded with undefined bits'



Why this inconsistency?



Nits/editorial comments:



1.   If the TLV definitions within the body of the RI LSA are identical, it 
would have been better to separate this in a distinct sub-section.

2.   Please include a reference to the Vendor Enterprise Code in section 5.2

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

[Daniel Migault]

Hi Joel, 

Thank you for taking time to review and comment the draft. 

We propose to add the following text to clarify the example in section 2 before 
the two last paragraphs. The following text expects to clarify the following 
points:
   - 1) The creation of VPN is a local policy matter
   - 2) Moving one duplicated VPN to different interfaces may involve multiple 
MOBIKE operations
   - 4) There is no needs to create all possible VPNs ( might be similar to 
item 1)

The following text has been added to our local copy. If you would like us to 
publish a new version, feel free to let us know. Our intention is to keep the 
updates local until you ask us to publish the draft.  

BR, 
Daniel and Valery

NEW TEXT -- BEGIN
Note that it is up to host's local policy which additional VPNs to create and 
when to do it. The process of selecting address pairs for migration is 
 a local matter. Furthermore, in the case of multiple interfaces on 
 both ends care should be taken to avoid the VPNs to be duplicated by both ends 
or moved to the both interfaces.

 In addition multiple MOBIKE operation may be involved from the 
 Security Gateway or the VPN End User.
 Suppose, as depicted in Figure 3 for example that the cloned VPN is 
 between Interface _0 and Interface_0', and the VPN End User and the 
 Security Gateway wants to move it to Interface_1 and Interface_1'. The 
 VPN End User may initiate a MOBIKE exchange in order to move it to 
 Interface_1, in which case the cloned VPN is now between Interface_1 
 and Interface_0'. Then the Security Gateway may also initiate a MOBIKE 
exchange in order to move the VPN to Interface_1' in which case the VPN has 
reached its final destination.
NEW TEXT -- END

-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com] 
Sent: Friday, October 02, 2015 1:25 PM
To: A. Jean Mahoney; General Area Review Team; 
draft-mglt-ipsecme-clone-ike-sa@ietf.org
Subject: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-mglt-ipsecme-clone-ike-sa-05.txt
Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)

Reviewer: Joel M. Halpern
Review Date: 2-Oct-2015
IETF LC End Date: 27-Oct-2015
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Propsoed Standard 
RFC.

Major issues:
 The introductory material talks about the case where both sides have 
multiple interfaces.  It is not clear what will happen with this mechanism in 
that case.
 In particular, if I have two systems, with three interfaces, it seems that 
this will start by creating the S1-D1 Security Association. 
It seems straightforward for each side to create their simple additional 
assocations (S2-D1, S3-D1, and S1-D2, S1-D3).
 But the introduction suggests that we also want to create S2-D2, S3-D3, 
S2-D3, and S3-D2.  With no other guidance, it appears that both sides will try 
to create all four of those, creating 8 security associations instead of 4.
 I hope that I have simply missed something in the document that resolves 
this.

Minor issues:

Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 - Editorial comments and nits

[Shraddha Hegde]

> -- 3.1.  TLV format
> 
>Type : TBA, Suggested value 10
> 
> Please add an RFC Editor Note asking the RFC Editor to replace this 
> with the actual IANA-assigned value.
>  Does the RFC Editor Note go as part of this document.

Yes, e.g.:

**RFC Editor: Please replace above TBA with the actual IANA-assigned value.

 Done.


> -- 4.5.  Explicit routing policy

The discussion of this example appears to warrant revision to reflect the 
preference vs. prohibition discussion around Major Issue [1].

 Request Bruno to update this section once we close on all other 
comments.


Rgds
Shraddha
-Original Message-
From: Black, David [mailto:david.bl...@emc.com] 
Sent: Wednesday, October 07, 2015 8:20 PM
To: Shraddha Hegde ; Rob Shakir ; 
a...@cisco.com; bruno.decra...@orange.com; ops-...@ietf.org; General Area 
Review Team (gen-art@ietf.org) ; lizhen...@huawei.com
Cc: a...@cisco.com; o...@ietf.org; i...@ietf.org; Black, David 

Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06 - 
Editorial comments and nits

Most of the nits/editorial comments are fine.  Two follow-ups:

> -- 3.1.  TLV format
> 
>Type : TBA, Suggested value 10
> 
> Please add an RFC Editor Note asking the RFC Editor to replace this 
> with the actual IANA-assigned value.
>  Does the RFC Editor Note go as part of this document.

Yes, e.g.:

**RFC Editor: Please replace above TBA with the actual IANA-assigned value.

> -- 4.5.  Explicit routing policy

The discussion of this example appears to warrant revision to reflect the 
preference vs. prohibition discussion around Major Issue [1].

Thanks,
--David

> -Original Message-
> From: Shraddha Hegde [mailto:shrad...@juniper.net]
> Sent: Wednesday, October 07, 2015 3:08 AM
> To: Black, David; Rob Shakir; a...@cisco.com; bruno.decra...@orange.com; 
> ops- d...@ietf.org; General Area Review Team (gen-art@ietf.org); 
> lizhen...@huawei.com
> Cc: a...@cisco.com; o...@ietf.org; i...@ietf.org
> Subject: RE: Gen-ART and OPS-Dir review of 
> draft-ietf-ospf-node-admin-tag-06
> 
> David,
> 
> Thanks a lot for your detailed review and comments.
> 
> Here are the details of responses. I have also attached the updated document.

[... snip ...]

> --- Nits/editorial comments: 
> 
> -- 1.  Introduction
> 
> The Abstract says that the tags are for "route and path selection"; 
> the Introduction should
> 
> also say that.  Suggestion - at the end of this sentence in the first
> paragraph:
> 
>It is useful to assign a per-node administrative tag to a router in
>the OSPF domain and use it as an attribute associated with the node.
> 
> add the text "for route and path selection".  This will help with the 
> second sentence in
> 
> the second paragraph:
> 
> Modified as per suggestion.
> 
>Path selection is a functional set
>which applies both to TE and non-TE applications and hence new TLV
>for carrying per-node administrative tags is included in Router
>Information LSA [RFC4970] .
> 
> If "path selection" and "functional set" are specific terms with 
> specialized meaning in
> 
> OSPF context, that sentence is fine as-is, otherwise it would read 
> better if it began with:
> 
>Route and path selection functionality applies to both ...
> 
>  Modified as per suggestion.
> 
> This document provides mechanisms to advertise per-node administrative 
> tags in OSPF for route and path selection. Route and path selection 
> functionality applies
> 
> to
> both to TE and non-TE applications and hence new TLV for carrying 
> per-node administrative tags is included in Router Information LSA ...
> 
> 
> 
> -- 3.1.  TLV format
> 
>Type : TBA, Suggested value 10
> 
> Please add an RFC Editor Note asking the RFC Editor to replace this 
> with the actual IANA-
> 
> assigned value.
>  Does the RFC Editor Note go as part of this document.
> 
> -- 3.2.  Elements of procedure
> 
> While it's obvious that tag usage should be confined to the 
> administrative domain that
> 
> understands the tag, it's worth stating.  At the end of this
> sentence:
> 
>Interpretation of tag values is specific to the administrative domain
>of a particular network operator.
> 
> I'd suggest adding:
> 
>, and hence tag values SHOULD NOT be propagated outside the
>administrative domain to which they apply.
> 
>  Modified as per suggestion
> 
> -- 4.4.  Mobile back-haul network service deployment
> 
> Please expand "eNodeB" acronym on first use.
> 
>  Added
> 
> -- 4.5.  Explicit routing policy
> 
> In Figure 3:
> - The link from the leftmost pair of A nodes to the pair of T nodes
>do not have link weights.
> - The link from the left R node to the left T node does not have a
>link weight
> - The following example of an explicitly routed policy:
> 
>   - Traffic from A nodes to I nodes must not go through R and T
>   nodes
> 
> prevents the leftmost pair of A nodes from sending traffic to the
> I nodes.  Was this "black hole" intended 

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: A-D issues

[Shraddha Hegde]

Thanks David for the follow-up.
Pls find details below.

[...Snip to open comments...]

David> Please add that statement, specifically that a receiver may have 
David> to ignore tags that do not match any local policies.  

Updated as below.

"If a receiving node does not
understand the tag value or does not have a local policy corresponding to the 
tag,
it ignores the specific tag and floods the RI LSA without any change as defined 
in ."


David> For the first requirement, I was expecting the "MUST" to apply 
David> only to "independent identifier," i.e.:

Each tag MUST be treated as an independent identifier that MAY be
used in policy to perform a policy action.

 OK. Updating the draft as suggested.

Each tag MUST be treated as an independent
identifier that MAY be used in policy to perform a policy
action. Tags carried by the administrative tag TLV SHOULD be used to indicate
independent characteristics of a node. The administrative tag list within the 
TLV MUST be considered 
an unordered list. Whilst policies may be implemented based on the 
presence of multiple tags (e.g., if tag A AND tag B are present), 
they MUST NOT be reliant upon the order of the tags (i.e.,
all policies should be considered commutative operations, such that
tag A preceding or following tag B does not change their outcome).



David> The last sentence appears to still have a problem:  How does a 
David> receiving node determine when it has a complete set of tags?  Suggested 
rephrase:

When an RI LSA is received that changes the set of tags applicable to
any originating node, a receiving node MUST repeat any computation or
processing that is based on those administrative tags.

David> I think that captures the underlying point that processing MUST 
David> always be based on current tag information.
  Updated as per suggestion

 Multiple node administrative tag TLVs MAY appear in an RI LSA or 
   multiple node administrative tag TLVs MAY be contained in different
   instances of the RI LSA.  The node administrative tags associated
   with a node that originates tags for the purpose of any computation or 
processing at a receiving node
   SHOULD be a superset of node administrative tags from all the TLVs in all the
   received RI LSA instances originated by that node.When an RI LSA is received 
that changes the set of 
   tags applicable to any originating node, a receiving node MUST repeat any 
computation or
processing that is based on those administrative tags.

-

David> I don't understand how a receiving node can be certain that a tag 
David> has been removed based on this sentence in Section 2:

   Multiple TLVs MAY be added in same RI-LSA or in a different instance
   of the RI LSA as defined in [I-D.acee-ospf-rfc4970bis].

David> How does a receiving node determine that it has seen all the 
David> relevant RI LSAs and hence that absence of a previously seen tag 
David> renders that tag no longer applicable?  The "seen all the 
David> relevant RI LSAs" portion of this answer probably belongs in Section 2.

 A node cannot determine that it has all the complete and current 
information at any point of time.
This is true for any link state IGP protocol which floods the data for 
distribution. 
The flooding mechanism is reliable and ensures the changes are propagated
Domain wide. The receivers have to process any database change and apply it to 
the entire link state database every-time it receives any change from any node.
This is so fundamental to the link state protocols, I don't see the necessity 
of repeating that concept in this document.


---

> [D] No management support
> 
> From OPS-Dir Q&A: At a minimum, reporting of tag values ought to be 
> defined via an OSPF MIB extension or analogous functionality.
> 
>  I think this should be taken separately as part of OSPF MIB 
> RFC update, which will combine multiple features which require new 
> definitions.
> 
> Acee, How do we go about this?

David> At the very least, the draft that updates that MIB should be referenced.

Currently there is no active draft working on OSPF MIB to update the 
node admin tag related configs.
 Yang data models are extensively being referred and recommended for management.
Have included a reference to the document and requested authors of yang draft 
to consider adding the node-admin-tag
Related interfaces to the data model.

7.  Manageability Considerations

   Node administrative tags are configured and managed using routing
   policy enhancements.  YANG data definition language is the latest
   model to describe and define configurat

Re: [Gen-art] Gen-ART review of draft-ietf-v6ops-siit-dc-2xlat-01

[Christer Holmberg]

Hi Tore,

I am happy with your suggestions on how to address my comments :)

Thanks!

Regards,

Christer

-Original Message-
From: Tore Anderson [mailto:t...@redpill-linpro.com] 
Sent: 7. lokakuuta 2015 12:54
To: Christer Holmberg
Cc: gen-art@ietf.org; draft-ietf-v6ops-siit-dc-2xlat@tools.ietf.org
Subject: Re: Gen-ART review of draft-ietf-v6ops-siit-dc-2xlat-01

Hi again Christer, and thanks again for reviewing!

* Christer Holmberg 

> Section 2 (Terminology):
> --
> 
> Q2_1: Many of the definitions have been defined in 
> draft-ietf-v6ops-siit-dc. Now they are re-defined, and sometimes with 
> a little different wording.
> 
> For those definitions, my suggestion would be to say:
> 
> "As defined in [draft-ietf-v6ops-siit-dc], a XXX is a blah blah blah"
> - copy/pasting the text from draft-ietf-v6ops-siit-dc.

Ack. I simply copied the definitions from -siit-dc (without the "As defined 
in..." prefix you proposed, since I think it would be rather repetitive).

The only definition that is not identical between -siit-dc and -siit-dc-2xlat 
now is the ER one; the [draft-ietf-v6ops-siit-dc-2xlat] reference is removed in 
-siit-dc-2xlat, instead your Q2_2 suggestion is added. Hope that's fine.

> Q2_2: In the Edge Relay, I think it would be good to mention the two 
> types (node-based and network-based).

Fixed. References to the appropriate sections defining the two variants also 
added.

> Section 4 (Deployment Considerations):
> ---
> 
> Q4_1:
> 
> The text in section 4.1. says:
> 
>  "The IPv6 Path MTU between the ER and the 
> BR will typically be larger than the default value defined in Section 
> 4 of [RFC6145] (1280),"
> 
> What is (1280)?

Bytes. Fixed.

> Section 5 (Intra-IDC IPv4 Communication):
> ---
> 
> Q5_1:
> 
> The text in section 5.1 says:
> 
> "If the BR supports hairpinning as described in Section 4.2 of I-D
>.ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam],"
> 
> I suggest to remove I-D.ietf-v6ops-siit-eam. The reference is enough.

Fixed.

> Section 7 (IANA Considerations):
> 
> 
> Q7_1: Do we normally remove the section if there are no requests from 
> IANA? Personally I prefer to keep the explicit "This draft makes no 
> request of the IANA." sentence.

Fixed.

> Section 8 (Security Considerations):
> 
> 
> Q8_1:
> 
> The text says:
> 
> "See the Security Considerations section in
>[I-D.ietf-v6ops-siit-dc] for additional security considerations
>applicable to the SIIT-DC architecture in general."
> 
> I suggest to remove "additional".

Fixed.

> Q8_2:
> 
> Is there a need to have section 8.1, or can all text be put in section 
> 8?

I supposed not. Fixed.

The changes implemented can be seen here:

https://github.com/toreanderson/ietf/commit/c22ca60c39eb0d98506ce7bae252cf5327be6acf

Please have a look and let me know if further changes are required, in your 
opinion. Thanks again!

Best regards,
Tore Anderson

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art