Subject: Re: [mpls] Working group last call on draft-ietf-mpls-seamless-mcast

From: Qin Wu <[email-masked]>
Date: Wed, 18 Jun 2014 11:30:02 +0000

Hi, authors:
I have read this draft and believe it is well written and ready for going for publication.
Here are a few editorial comments:
1. Section 3, the 10th paragraph said:
"
The backbone area segment has as its leaves ABRs that are
connected to the egress area(s) or PEs in the backbone area, or ASBRs
in the backbone area.
"
[Qin]: what does "has as its leaves ABRs" mean? Should it be "has its leaves ABRs"

2. Section 3, the 11th paragraph said:
"
The egress area segment is rooted at an ABR in the egress area
(egress ABR), and has as its leaves PEs and ASBR in that egress area
(the latter covers the case where the P2MP service LSP spans multiple
ASes).  
"
[Qin]: s/has as/has

3. Section 6.2.3, the 2nd paragraph said:
"
The upstream node's address is as
determined in section 6.1  ("Determining the Upstream ABR/PE/ASBR
(Upstream Node)").
"
[Qin]: For consistency, would it be good to rephrase as
"
The upstream node's address is 
determined as specified section 6.1  ("Determining the Upstream ABR/PE/ASBR
(Upstream Node)").
"

4. Section 6.3.1.1 said:
"
   Similarly
   whenever as a result of receiving MSDP messages a PE, that is not
   configured as a RP, discovers a new multicast source the PE SHOULD
   originate a BGP Source Active A-D route.
"
[Qin]: s/ messages a PE, that is not/ messages, a PE that is not

5. Section 6.3.1.2 said:
"
When as a result of receiving PIM or IGMP messages on one of its IP
   multicast interfaces an (egress) PE  creates in its Tree Information
"
[Qin]: why "(egress) PE" not "egress PE"? does PE includes other type of PE as well?

6. Section 12 said:
"
   By default if the received S-PMSI A-D route carries the
   Inter-area P2MP Segmented Next-Hop Extended Community, then the
   originated S-PMSI A-D route SHOULD  also carry this community.
"
[Qin]: Why SHOULD not MUST?
What if the community is not carried in the originated S-PMSI A-D route?

7. Section 13.3 said:
"
An Ingress PE must perform application specific forwarding procedures
   to identify the outgoing inta-area  segment of an incoming packet.
"
[Qin]: s/inta-area/intra-area

8. Section 14 said:
"
14. Support for Inter-Area Transport LSPs 

   This section describes OPTIONAL procedures that allow to aggregate
   multiple (inter-area) P2MP service LSPs into a single inter-area P2MP
   transport LSP, and then apply the segmentation procedures, as
   specified in this document, to these inter-area P2MP transport LSPs
   (rather than applying these procedures directly to the inter-area
   P2MP service LSPs).
"
[Qin]: since the procedures proposed in section 14 is optional, why not move these procedures to appendix of this document?

-------- Original Message --------
Subject: Working group last call on draft-ietf-mpls-seamless-mcast
Date: Mon, 09 Jun 2014 05:24:37 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked] <[email-masked]>
CC: [email-masked]
<[email-masked]>,
[email-masked] <[email-masked]>,  VIGOUREUX, MARTIN (MARTIN) <[email-masked]>

Working Group,

This is to initiate a two week working group last call on draft-ietf-mpls-seamless-mcast.

There are one IPR disclosure against this document. The authors has stated that he is unaware of any other IPRs that relate to this document.

Please send your comments to the mpls wg mailing list ([email-masked]).

This working group last call ends June 23, 2014.

/Loa
for the MPLS wg chairs
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 18 Jun 2014 13:44:22 -0700

Qin,

> I have read this draft and believe it is well written and ready for going for

Many thanks for your review and comments.

> [Qin]: what does "has as its leaves ABRs" mean? Should it be "has its leaves 

Sure.

> (the latter covers the case where the P2MP service LSP spans multiple

Sure.

> determined as specified section 6.1  ("Determining the Upstream ABR/PE/ASBR

Sure.

> [Qin]: s/ messages a PE, that is not/ messages, a PE that is not

Sure.

> [Qin]: why "(egress) PE" not "egress PE"? does PE includes other 

I'll delete the parenthesis.

> What if the community is not carried in the originated S-PMSI A-D route?

Note that "SHOULD" applies to the *default* behavior. In fact, the
previous sentence makes its clear that it should be possible
to override the default behavior via config:

                                                            the V-hub
   SHOULD be able to control via configuration whether the Inter-area
   P2MP Segmented Next-Hop Extended Community, if present in the
   received S-PMSI A-D route, be also carried in the originated S-PMSI
   A-D route.

Thus it should be possible via config for the originated S-PMSI
A-D routes *not* to carry the community.

> [Qin]: s/inta-area/intra-area

Sure.

> [Qin]: since the procedures proposed in section 14 is optional, why not move 
> these procedures to appendix of this document?

I don't think there are rules that say that optional procedures should be
moved to the appendix. However, I don't have a strong opinion on this.
Given all this, I'd like WG chairs advise on whether to keep the text
in its present place, or move it to an appendix.

Yakov.

> [email-masked] <[email-masked]>,  VIGOUREUX, MARTIN (
MARTIN) <[email-masked]>
> There are one IPR disclosure against this document. The authors has stated th
at he is unaware of any other IPRs that relate to this document.
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Jun 2014 01:30:20 +0000

> What if the community is not carried in the originated S-PMSI A-D route?

Note that "SHOULD" applies to the *default* behavior. In fact, the previous sentence makes its clear that it should be possible to override the default behavior via config:

                                                            the V-hub

Thus it should be possible via config for the originated S-PMSI A-D routes *not* to carry the community.

[Qin]: Make sense to me, thanks for your clarification.

> [Qin]: since the procedures proposed in section 14 is optional, why 
> not move these procedures to appendix of this document?

I don't think there are rules that say that optional procedures should be moved to the appendix. However, I don't have a strong opinion on this.
Given all this, I'd like WG chairs advise on whether to keep the text in its present place, or move it to an appendix.

[Qin]: You are right, I have no objection to either of your proposals.

Yakov.

> 
> Working Group,
> 
> This is to initiate a two week working group last call on 
> draft-ietf-mpls-sea
mless-mcast.