Re: [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt

["Lizhong Jin" <[e-mail]>]

Hi Eric,
Thanks for the prompt reply. See inline below.

Regards
Lizhong

> -----Original Message-----
> From: Eric Rosen [mailto:[e-mail]]
> Sent: 2014年8月10日 7:23
> To: Lizhong Jin
> Cc: rtg-ads; draft-ietf-mpls-mldp-in-band-wildcard-encoding; rtg-dir; mpls
> Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-
> encoding-01.txt
> 
> Many thanks for your review and comments!
> 
>   Section 1
> 
>     When an MP-LSP is being set up, the procedures of [RFC6826] and
>     [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] , known as "mLDP In-Band
>     Signaling", allow the Egress LSRs of the MP-LSP to encode the
identifier
>     of an IP multicast tree in the "Opaque Value" field of the mLDP FEC
>     Element that identifies the MP-LSP.
> 
> Lizhong> The reference [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]
> Lizhong> should be moved to the next section, right? This section is
> Lizhong> talking about RFC6826.
> 
> I think the material in this paragraph is applicable in VRF context as
well as in
> non-VRF context.  Thus it is appropriate to reference both RFC 6826 (which
> discusses in-band signaling in non-VRF context) and RFC 7246 (formerly
draft-
> ietf-l3vpn-mldp-vrf-in-band-signaling), which discusses in-band signaling
in
> VRF context.
> 
> The material in the following paragraph only applies in VRF context.  I
will add
> a reference to RFC 7246 to that paragraph.
[Lizhong] OK

> 
> 
>   Section 3.2
> 
>     Please note that, as always, the structure of the Opaque Value TLVs
does
>     not actually affect the operation of mLDP, but only affects the
>     interface between mLDP and IP multicast at the Ingress LSR.
> 
> Lizhong> the interface between mLDP and IP multicast at the egress LSR
> Lizhong> is also affected. So it is better to say "...at the Ingress and
> Lizhong> Egress LSR".
> 
> How about:
> 
>     Please note that, as always, the structure of an Opaque Value TLV does
>     not affect the operation of mLDP.  The structure is meaningful only to
>     the IP multicast modules at the ingress and egress LSRs.
[Lizhong] OK with that.

> 
> 
>   Section 3.2
> 
>     Note that the Bidir TLVs do not have a "Source Address" sub-field, and
>     hence the notion of a wildcard source is not applicable to them.
> 
> Lizhong> since Bidir TLV is out of the scope, then it is not necessary
> Lizhong> to have the above note.
> 
> Section 3.2 states earlier that procedures for the use of the wildcard
group in
> the Bidir TLVs are out of scope.  The sentence cited above says that the
Bidir
> TLVs cannot have a wildcard source.  I think it is useful to make both
> statements, since neither one implies the other.
[Lizhong] OK

> 
>   Section 3.3
> 
>     However, if an Ingress LSR supports [RFC6826] and/or
>     [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling], but does not support this
>     document, it has no choice but to treat any such received FEC elements
>     as invalid; the procedures specified in [RFC6826] and
>     [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] do not work when the
Opaque
>     values contain zeroes in the Source Address or Group Address
sub-fields.
> 
> Lizhong> I went throught RFC6826 and RFC7246, there is no definition of
> Lizhong> "zeroes". Then the above statement will be treated as an update
> Lizhong> to
> Lizhong> RFC6826 and RFC7246. If that is true, then the draft header
> Lizhong> needs to indicate that update.
> 
> I believe you are correct.  I will add this to the draft header and the
abstract.
[Lizhong] OK

> 
>   Section 5.
> 
>     If PIM is not enabled for the identified group, the Ingress LSR acts
as
>     if it had received a (*,G) IGMP/MLD report from a downstream node, and
>     the procedures as defined in [RFC4605] are followed.
> 
> Lizhong> It seems the dataplane processing is missing here. E.g., add
> Lizhong> something like, the ingress LSR should forward the specified
> Lizhong> multicast stream to the downstream node through the MP-LSP
> Lizhong> identified by the Opaque Value TLV. That is not described in
> Lizhong> RFC4605.
> 
> This is discussed in section 4.2 of the document; I think it will be
adequate to
> just add a reference here to section 4.2.
[Lizhong] The description in section 4.2 is also implicit for the packet
forwarding behavior. Did I miss something? Section 6 has very clear
description: 
   All these streams SHOULD be forwarded down the MP-LSP
   identified by the Opaque Value TLV.

Regards
Lizhong