headers
Stewart Bryant | 1 May 2009 12:55
Picon
Favicon

WG Last Call for draft-ietf-pwe3-oam-msg-map-10


This is the WG Last Call for

draft-ietf-pwe3-oam-msg-map-10

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-10.txt

Please send comments to the list by Friday 22nd May

Thanks

Stewart
Permalink | Reply | 1 comment |
headers
Stewart Bryant | 1 May 2009 13:46
Picon
Favicon

Re: Should draft-martini-pwe3-iccp-01 be a WG doc?

Stewart Bryant wrote:
> The authors of draft-martini-pwe3-iccp-01.txt
>
> http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt
>
> have requested that this become a PWE3 WG document.
>
> Please can you send comments to the list by 20th April
> so that the chairs can judge consensus.
>
> Thanks
>
> Stewart
> _______________________________________________
> pwe3 mailing list
> pwe3 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>
Reviewing the comments there is clear consensus
that we need a standard method for ICCP.

This is the only draft that has been put forward
to define a mechanism.

There is some concern that transports other
than LDP should be provided, and some
concern that the use of the mechanism should
be generalized to support other types of
PE, and not just PWE3 PEs. However no
such general mechanism has been proposed
(Continue reading)

Permalink | Reply | 0 comments |
headers
BOCCI Matthew | 1 May 2009 14:39
Favicon

Re: draft-bryant-filsfils-fat-pw-03 to WG draft?

There is consensus to accept this draft as a PWE3 working group draft.
 
Authors: please update the draft as per the discussion on the list and correct the title to include the PWE3 working group name.
 
Please note that in accepting this draft as a Working Group Draft, we are not precluding other, different load balancing mechanisms that address a different scope or problem space from being adopted by PWE3.
 
Regards
 
Matthew
 

From: pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org] On Behalf Of BOCCI Matthew
Sent: 31 March 2009 12:51
To: pwe3 <at> ietf.org
Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?

This is the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03
 to a PWE3 Working Group draft.

Please can you respond to the PWE3 list with your approval (or otherwise).

This poll will close on 14th April 2009.

Regards

Matthew 


_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 0 comments |
headers
Stewart Bryant | 1 May 2009 15:51
Picon
Favicon

WG Last Call for draft-ietf-pwe3-segmented-pw


This is the WG Last Call for draft-ietf-pwe3-segmented-pw-11

http://tools.ietf.org/html/draft-ietf-pwe3-segmented-pw-11

Please send comments to the list by Friday 22nd May

Thanks

Stewart
Permalink | Reply | 0 comments |
headers
Loa Andersson | 4 May 2009 17:24
Picon

working group last call on draft-ietf-mpls-tp-nm-req-01.txt

ALL,

This is to start a two week working group last call on

draft-ietf-mpls-tp-nm-req-01.txt

Please send your comments to the mpls-tp mailing list.

This working group last call is joint between the mpls,
ccamp. Pwe3 and l2vpn.

The working group lst call ends on May 19th eob.

/Loa

--

-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13 

                                       email:  loa.andersson <at> ericsson.com
                                               loa.andersson <at> redback.com
                                               loa <at> pi.nu

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
frederic.jounay | 5 May 2009 16:03

TR: Re: Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01

Hi Sherry,

Thanks for the comments
Please see my answer inline marked [FJ]

Regards,
Fred

-----Message d'origine-----
De : Sherry Xue [mailto:xueli <at> huawei.com] Envoyé : samedi 25 avril 2009 09:42 À : JOUNAY Frederic
RD-RESA-LAN Cc : pwe3 <at> ietf.org Objet : Re:Re: Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01

Hi, Fred,
I totally agree with your opinion that the leaf-initiated mode and source-initiated mode are not
restricted in the application of SS-PW and MS-PW.
IMO, leaf initiated mode is more conveniently for MS-PW, and in the source initiated mode, more work should
be considered for MS-PW, such as AD and PW routing. I agree the standardization work course with
admiration. 
[FJ] Yes, it's true, we probably need both setup modes depending on SP requirements. That's why we tried to
define a new multicast FEC element which could fit to both. 

For P2MP SS-PW setup in leaf-initiated mode, it may be divided into two
instances:
[FJ] I think you mean P2MP MS-PW?
1)over P2P PSN :
this case may be according to MP2P signaling, similarly as star-topology(logically), in which P2MP SS-PW
is composed of m(leaf no.)*P2P SS-PW, and all the P2P SS-PWs should be setup individually without
consideration of the merge-node(physically). That is to say in the merge node, there will be different
labels allocated upstream for different downstream T-PEs.
[FJ] In that case the downstream Label assignment should be considered, is it what you mean?

2) over P2MP PSN
The merge-node should record the Label(called label L) allocated by the downstream TAII(called  X) with
SAII( S ), and if another signaling message from other TAII(i.e.,Y) is received with same SAII, the
merge-node should allocated label L for TAII Y(upstream label assignment), and then allocate upstream
label to next upstream hop. 
IMO, if the P2MP PW is initiated by the leafs, the PSN tunnel should be restrict to P2P, because it sounds
illogical that the leaf node is used to manage a P2MP LSP or PW? What about your opinion?
[FJ] I think if we consider PW segments over P2MP LSP, we must consider only the upstream Label assignment.
Because in your first step you derscribe, the dowstream Label assigned by the first Leaf could be already
in use by another P2MP PW.  
I've the feeling we may have the requirement to define P2MP MS-PW/P2MP LSP, and this would require Leaf PE to
request the upstream PW P2MP Label for this segment. We need more feedbazck on it from the WG

For P2MP MS-PW setup in source-initiated mode, the explicit routing should be provided in the source PE. So
the LDP should be extended for MS-PW setup according explicit routing. Right? Whether the explicit
routing is the only method for the PW routing? 
[FJ] the explicit routing mode is not mandatory for the source-initiated solution.

Regarding the P2P PW setup procedure, there are two protocols, LDP and BGP.
Could we use BGP for P2MP PW setup?
[FJ] Rahul has proposed an ID for P2MP PW setup based on BGP, derived from the VPLS multicast solution. Based
on existing deployment around L2VPN, the SP may need to both solutions (LDP, and BGP) http://www.potaroo.net/ietf/idref/draft-raggarwa-l2vpn-p2mp-pw/

Best wishes and regards
Sherry

> Hi Xinquan
> 
> "In my opinion, your original intention is to propose leaf-initiated 
> mode
as
> a solution for inter-domain scenario, and source-initiated mode for 
> intra-domain scenario. Am I right?"
> 
> not really, actually both procedures (leaf or source initiated)  are 
> not limited in their operating principles and as such could be used  
> to cover
SS-PW
> and MS-PW configuration.
> For the standardization work we propose to focus first on P2MP SS-PW  
> as
it
> is the simplest configuration, to agree on the required new  building
blocks :
> FEC element, signaling procedures etc...
> The part related to P2MP SS-PW setup in the leaf-initiated draft and 
> the
part
> related to P2MP MS-PW setup in the source-initiated draft should be 
> added
asap
> or considered in a separate document.
> 
> Regarding their network applicability the choice between both 
> approaches
will
> have to be made on a case by case basis, driven by architectural and
operational
> constraints. For the moment we felt the need to investigate both 
> solutions
in
> parallel.
> 
> Do you have any comment on the applicability of the two approaches ?  
> Or
any
> specific requirement that would need to be included in the 
> requirements
draft
> on P2MP PW ?
> 
> Best Regards,
> 
> Fred
> 
> ________________________________
> 
> De : l2vpn-bounces <at> ietf.org [mailto:l2vpn-bounces <at> ietf.org] De la part 
> de zhang.xinquan <at> zte.com.cn Envoy? : mardi 21 avril 2009 03:23 ? : 
> JOUNAY Frederic RD-RESA-LAN Cc : l2vpn <at> ietf.org; 
> l2vpn-bounces <at> ietf.org; pwe3 <at> ietf.org Objet : ??: RE: Comments on 
> draft-jounay-pwe3-leaf-initiated-p2mp-pw-01
> 
> 
> 
> Hi Frederic,
> 
> Thanks for your clarificaton.
> 
> You have two drafts about P2MP PW signaling, one is leaf-initiated 
> mode
and
> the other is source-initiated mode. In my opinion, your original 
> intention
is
> to propose leaf-initiated mode as a solution for inter-domain 
> scenario,
and
> source-initiated mode for intra-domain scenario. Am I right? Or your 
> have
other
> considerations?
> 
> Best regards!
> 
> Xinquan Zhang
> 
> 2009/4/21
> 
> 
> 
> 
> 
> <frederic.jounay <at> orange-ftgroup.com>
> ???:  l2vpn-bounces <at> ietf.org
> 
> 2009-04-20 20:55
> 
> ???
> <zhang.xinquan <at> zte.com.cn>
> ??
> l2vpn <at> ietf.org, l2vpn-bounces <at> ietf.org, pwe3 <at> ietf.org ??
> RE: Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01
> 
> 
> 
> 
> 
> 
> Hi Xinquan,
> 
> Please see my answer inline [FJ]
> 
> Best Regards,
> Fred
> 
> 
> ________________________________
> 
> De : zhang.xinquan <at> zte.com.cn [mailto:zhang.xinquan <at> zte.com.cn] Envoy? 
> : mercredi 15 avril 2009 07:50 ? : JOUNAY Frederic RD-RESA-LAN Cc : 
> l2vpn <at> ietf.org; l2vpn-bounces <at> ietf.org Objet : Comments on 
> draft-jounay-pwe3-leaf-initiated-p2mp-pw-01
> 
> 
> Hi, Frederic,
> 
> I have read draft-jounay-pwe3-leaf-initiated-p2mp-pw-01 and have some 
> comments. please see below:
> 
> 1?section 5.4. Configuration
> 
>   After configuring on each T-PE the attached AIIs, it is assumed that
>   all the PEs (Ingress/Egress T-PEs and all S-PEs) maintain an AII PW
>   routing table which gives for each AII as entry the "next hop" to
>   reach that AII. This AII routing table can be filled manually or
>   updated dynamically by means of some extended routing protocol like
>   proposed in [DYN MS-PW]. The construction of the table is out of
>   scope of the present document.
> 
>   Each PE relies on its AII PW routing table to select the next hop PE
>   (S-PE or T-PE) to reach a given AII.
> 
> >1  Does this AII routing table include both TAII and SAII?
> [FJ] Yes, the AII routing table dynamically populated (BGP, OSPF, 
> IS-IS or
LDP)
> should maintain both. The Egress T-PE joins the PW tree by initiating 
> a
Label
> Map whose the FEC contains the SAII, the PW tree source. Hence upon
receipt
> of the message the S-PE does a lookup to select the NH to reach this SAII.
> >2  In S-PE, this AII routing table includes all the AII, or just part 
> >of
the
> AII( e.g. which are in its dowstream)?
> [FJ] the AII routing table should be used also for VPWS or VPLS, so
bidirectional
> PW. Therefore the AII routing table must reflect all the AII 
> configured on
T-PEs.
> Of course agregate AII format (i.e. w/o ACID info) as defined in [DYN
MS-PW]
> must be used to optimize the AII routing table
> 
> 2?Section 5.7. Using TAII Leaf Sub-TLV
> 
>   Section TBD
> 
>   The TAII Leaf sub-TLV MAY be optionally used when a leaf joins the PW
>   tree to announce to the source that it is part from the PW tree. If
>   this option is chosen, the Egress T-PE adds to the FEC Element this
>   TAII sub-TLV in the Label Map message. As soon as in the source
>   direction a Label Map is not required since for instance a S-PE
>   already maintains a state for this MS-PW tree, the information
>   related to the Leaf TAIIs is retrieved from the TAII Leaf sub-TLV and
>   is propagated by means of a LDP Notification message up to the
>   corresponding Ingress T-PE.
> > I am not sure about the propagation of TAII Leaf sub-TLV. Is it sent 
> > to
ingress
> T-PE directly, or to the upstream S-PE(if there exists such S-PE in 
> the
upstream
> direction)?
> [FJ] The Notification message can not be directly sent to the Ingress 
> T-PE
if
> there is not direct T-LDP session to reach the Ingress T-PE, i.e. S-PE 
> in
between.
> That's the reason why the message should be propagated hop by hop (i.e.
S-PE
> by S-PE) up to the Ingress T-PE.
>  I agree with you that's worth clarifying this section.
> 
> Best Regards!
> 
> Xinquan Zhang
> 
> 2009/4/15
> 
> 
> 
> -------------- next part -------------- An HTML attachment was 
> scrubbed...
> URL:
> <http://www.ietf.org/mail-archive/web/pwe3/attachments/20090421/6a21e3
> e1/a
> ttachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> pwe3 mailing list
> pwe3 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> 
> 
> End of pwe3 Digest, Vol 60, Issue 26
> ************************************
Permalink | Reply | 2 comments |
headers
AISSAOUI Mustapha | 6 May 2009 00:00
Favicon

Re: draft-ietf-pwe3-vccv-bfd-03.txt WG last call

All,
I had a discussion with Peter regarding my comment (1) below and he is right that the behaviour I quoted from Section 3.1 of this draft is actually supported in the BFD base draft. However, the two directions are not completly independent from a state machine perspective. Although the session failure detection is always performed by the egress PE in the receive direction and it then notifies the ingress PE using the Diagnostic Code 1 (Control Detection Time Expired), the egress PE cannot transition BFD session back to the UP state unless the ingress PE signaled back a Diagnostic code 3 (Neighbor signaled session down) or an Init value in the Sta flags. I think it would be useful to add this detail in Section 3.1.
 
I appreciate if the authors also updated the terminology for the "forward defect"  and "reverse defect" PW states to match the new terminology used in draft-ietf-pwe3-oam-msg-map.
 
My comment on draft-ietf-pwe3-oam-msg-map still holds since there is no such a thing as "ingress PE detection of failure" with BFD. Peter already updated this in version 10 of the draft. Thanks.
 
Also, please ignore my comment (2) regarding the reply mode. Each PE encapsulates the BFD packets according to one of the two encapsulation methods as per the negotiated CV type. There is no need for sending BFD messages out-of-band.
 
I have not seen a response to the other comments below.
 
Regards,
Mustapha.

From: Busschbach, Peter B (Peter) [mailto:busschbach <at> alcatel-lucent.com]
Sent: Wednesday, April 08, 2009 3:23 PM
To: AISSAOUI Mustapha; BOCCI Matthew; pwe3 <at> ietf.org
Subject: RE: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call

MA> I do not believe that BFD as defined today supports this mode of operation. This mode requires that each
MA> PE be able to declare the PW to be down in the receive direction independently based on not receiving a
MA> number of BFD control messages during a number of time intervals. This mode would be similar to the way
MA> ATM and Ethernet CC work.
 
Mustapha,
 
I had a different interpretation of the way BFD works. In the asynchornous mode, which the vccv-bfd draft prescribes, each end point checks for the arrival of control messages sent by the remote end. If it does not receive control messages, it enters the DOWN state. This is specified in section 6.2.
 
Since the flow of control messages consists of two independent, uni-directional flows, isn't it true that the downstream PE can autonomously declare a receive defect?
 
Peter

From: pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org] On Behalf Of AISSAOUI Mustapha
Sent: Wednesday, April 08, 2009 10:21 AM
To: Bocci, Matthew (Matthew); pwe3 <at> ietf.org
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call

Dear all,
as requested by Matthew, I reviewed this draft and I have compiled my comments below.
 
Regards,
Mustapha.
---------------------------------------------------

Comments

on draft-ietf-pwe3-vccv-bfd-03

1. Section 3.1, last paragraph states:

"

When the downstream PE (D-PE) does not receive BFD control messages from its upstream peer PE (U-PE) during a certain number of transmission intervals (a number provisioned by the operator as Detect Mult), D-PE declares that the PW in its receive direction is down. In other words, D-PE enters the "forward defect" state for this PW. After this calculated Detection Time, D-PE declares the session Down, and signals this to the remote end via the State (Sta) with Diagnostic code 1 (Control Detection Time Expired). In turn, U-PE declares the PW is down in its transmit direction setting the State to Down, and it using Diagnostic code 3 (Neighbor signaled session down) in its control messages to D-PE. U-PE enters the "reverse defect" state for this PW. If needed, how it further processes this error condition, and conveys this status to the attachment circuits is out of the scope of this specification, and is instead defined in [I-D.ietf-pwe3-oam-msg-map].

"

MA> I do not believe that BFD as defined today supports this mode of operation. This mode requires that each PE be able to declare the PW to be down in the receive direction independently based on not receiving a number of BFD control messages during a number of time intervals. This mode would be similar to the way ATM and Ethernet CC work.

However, BFD requires that the sender of the messages declares the state of the PW to be down if replies to its own BFD messages were not received for a number of time intervals.

Given that, the sender cannot tell which direction of the PW is down, it must enter the PW receive defect state as explained in draft-ietf-pwe3-oam-msg-map-09.txt. However, the receiver of the messages can send a BFD status change asynchronously and in this case the sender can be sure the defect is in the forward direction, which means it must enter the PW trasmit defect state.

I believe Appendix B of draft-ietf-pwe3-oam-msg-map-09.txt must also be corrected as it states:

"

Furthermore, the detection of a fault could occur at different points in the network and there are several ways the observing PE determines a fault exists:

a. egress or ingress PE detection of failure (e.g. BFD)

….

"

2. Section 3.2 - BFD Encapsulation

MA> We need to document how the reply to the BFD packet is encapsulated. The following reply modes of "

2- Reply via an IPv4/IPv6 UDP packet", "3 - Reply via an IPv4/IPv6 UDP packet with Router Alert", and "4 - Reply via application level control channel" must be documented for the UDP/IP encapsulation. The PW-ACH necapsulation can only support reply mode 4 since it cannot be routed. I believe the relevant text for this is covered in draft-ietf-bfd-mpls-07.txt.

3. Section 3.3, item (3) reads:

"

4. Pseudowires that do not use a CW or L2SS using the PW Associated Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers).

A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), and MPLS CC Types 2 and 3 when using a Control Word (as specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This restriction stems from the fact that the PW-ACH contains a Protocol Identification (PID) field, the Channel Type.

B. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation with IP/UDP headers, including its concurrent use along with another CV Type that uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping). For example, as specified in Section 7 of [RFC4385], a Pseudowire operating without CW MUST NOT use the PW-ACH.

"

MA> This paragraph is trying to convey too many things and is confusing. I propose we split it into the case of PW with ACH and PW with no ACH. Here is a proposal which I believe covers all the intended points:

"

4. A PW that uses the PW-ACH must signal CC Type 1 only in the VCCV parameter included in the interface parameter field of the PW ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as described in [RFC 5085].

5. A PW that does not use a PW-ACH must signal CC Types 2 and/or 3 in the VCCV parameter included in the interface parameter field of the PW ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as described in [RFC 5085]. For example, this can be a PW which is configured not to use the CW on the user packets. As specified in Section 7 of [RFC4385], this PW MUST NOT use the PW-ACH.

6. A

PW that does not use the PW-ACH MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers). This restriction stems from the fact that the PW-ACH contains a Protocol Identification (PID) field, the Channel Type, which is the only way to identify BFD messages with these CV types.

7. A PW can use the VCCV BFD encapsulation with IP/UDP headers, including its concurrent use along with another CV type that uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping), regardless if it is configured to use PW-ACH or not.

"

5. Section 3.3, item (4)

"

4. Only a single BFD CV Type can be selected and used. All BFD CV Types are mutually exclusive with the rest, after selecting a BFD CV Type, a node MUST NOT use any of the other three BFD CV Types.

"

MA> It must be stated that in order to change the negotiation and selection of the BFD CV types, the PW must be torn down and re-signaled.

---------------------------------------------------
From: pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org] On Behalf Of BOCCI Matthew
Sent: Monday, March 09, 2009 11:09 AM
To: pwe3 <at> ietf.org
Subject: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call

This is the start of working group last call on draft-ietf-pwe3-vccv-bfd-03.txt

This draft can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt

The last call will close on Monday 6th April 2009.

Please read the document and provide feedback to the PWE3 list.

Many thanks to the following, who have also kindly agreed to review the draft and provide comments to the list:
Ben Niven-Jenkins
Mustapha Aissaoui
Luca Martini
Yaakov Stein

Best regards

Matthew 



_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 5 comments |
headers
Carlos Pignataro | 6 May 2009 02:41
X-Face
Picon
Favicon

Re: draft-ietf-pwe3-vccv-bfd-03.txt WG last call

Hello Mustapha,

Many thanks for your review and comments, and sorry for the much belated
reply. Please see inline responses to the 4 issues you raised, I hope
these help.

On 4/8/2009 10:21 AM, AISSAOUI Mustapha wrote:
> Dear all,
> as requested by Matthew, I reviewed this draft and I have
> compiled my comments below.
>  
> Regards,
> Mustapha.
> ---------------------------------------------------
> 
> Comments on draft-ietf-pwe3-vccv-bfd-03
> 
> 1. Section 3.1, last paragraph states:
> 
> "
> 
> When the downstream PE (D-PE) does not receive BFD control messages from
> its upstream peer PE (U-PE) during a certain number of transmission
> intervals (a number provisioned by the operator as Detect Mult), D-PE
> declares that the PW in its receive direction is down. In other words,
> D-PE enters the "forward defect" state for this PW. After this
> calculated Detection Time, D-PE declares the session Down, and signals
> this to the remote end via the State (Sta) with Diagnostic code 1
> (Control Detection Time Expired). In turn, U-PE declares the PW is down
> in its transmit direction setting the State to Down, and it using
> Diagnostic code 3 (Neighbor signaled session down) in its control
> messages to D-PE. U-PE enters the "reverse defect" state for this PW. If
> needed, how it further processes this error condition, and conveys this
> status to the attachment circuits is out of the scope of this
> specification, and is instead defined in [I-D.ietf-pwe3-oam-msg-map].
> 
> "
> 
> MA> I do not believe that BFD as defined today supports this mode of
> operation. This mode requires that each PE be able to declare the PW to
> be down in the receive direction independently based on not receiving a
> number of BFD control messages during a number of time intervals. This
> mode would be similar to the way ATM and Ethernet CC work.
> 
> However, BFD requires that the sender of the messages declares the state
> of the PW to be down if replies to its own BFD messages were not
> received for a number of time intervals.
> 

1. I believe Peter already addressed this comment (thanks, Peter !). In
addition to the independent flows argument, see the usage of the Diag code.

> Given that, the sender cannot tell which direction of the PW is down, it
> must enter the PW receive defect state as explained in
> draft-ietf-pwe3-oam-msg-map-09.txt. However, the receiver of the
> messages can send a BFD status change asynchronously and in this case
> the sender can be sure the defect is in the forward direction, which
> means it must enter the PW trasmit defect state.
> 
> I believe Appendix B of draft-ietf-pwe3-oam-msg-map-09.txt must also be
> corrected as it states:
> 
> "
> 
> Furthermore, the detection of a fault could occur at different points in
> the network and there are several ways the observing PE determines a
> fault exists:
> 
> a. egress or ingress PE detection of failure (e.g. BFD)
> 
> ….
> 
> "
> 
> 2. Section 3.2 - BFD Encapsulation
> 
> MA> We need to document how the reply to the BFD packet is encapsulated.
> The following reply modes of "2- Reply via an IPv4/IPv6 UDP packet", "3
> - Reply via an IPv4/IPv6 UDP packet with Router Alert", and "4 - Reply
> via application level control channel" must be documented for the UDP/IP
> encapsulation. The PW-ACH necapsulation can only support reply mode 4
> since it cannot be routed. I believe the relevant text for this is
> covered in draft-ietf-bfd-mpls-07.txt.

2. These are MPLS Echo reply modes from
<http://tools.ietf.org/html/rfc4379#section-3> and not BFD. RE OOB, for
all cases, vccv-bfd S3.1 says:

   The BFD control packets are sent on the VCCV control channel.
...
   The operation of BFD VCCV for PWs is therefore symmetrical.  Both
   endpoints of the bidirectional pseudowire MUST send BFD messages on
   the VCCV control channel.

I don't think this comment applies.

> 
> 3. Section 3.3, item (3) reads:
> 
> "
> 
> 4. Pseudowires that do not use a CW or L2SS using the PW Associated
> Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH
> encapsulation of BFD, without IP/UDP headers).
> 
> A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 as
> defined in Sections 5.1.1 and 6.1 of [RFC5085]), and MPLS CC Types 2 and
> 3 when using a Control Word (as specified in Sections 5.1.2 and 5.1.3 of
> [RFC5085]). This restriction stems from the fact that the PW-ACH
> contains a Protocol Identification (PID) field, the Channel Type.
> 
> B. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation with
> IP/UDP headers, including its concurrent use along with another CV Type
> that uses an encapsulation with IP headers (e.g., ICMP Ping or LSP
> Ping). For example, as specified in Section 7 of [RFC4385], a Pseudowire
> operating without CW MUST NOT use the PW-ACH.
> 
> "
> 
> MA> This paragraph is trying to convey too many things and is confusing.
> I propose we split it into the case of PW with ACH and PW with no ACH.
> Here is a proposal which I believe covers all the intended points:
> 

Yes, it is a bit of a long para, however the issue is that the ordered
list is hierarchical and not plain. I mean, "A" and "B" are subordinates
to "3". Stewart already mentioned this in his review, and we'll be
changing this to "3.1" instead of "A".

> "
> 
> 4. A PW that uses the PW-ACH must signal CC Type 1 only in the VCCV
> parameter included in the interface parameter field of the PW ID FEC TLV
> or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as
> described in [RFC 5085].
> 
> 5. A PW that does not use a PW-ACH must signal CC Types 2 and/or 3 in
> the VCCV parameter included in the interface parameter field of the PW
> ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID
> FEC TLV as described in [RFC 5085]. For example, this can be a PW which
> is configured not to use the CW on the user packets. As specified in
> Section 7 of [RFC4385], this PW MUST NOT use the PW-ACH.
> 
> 6. A PW that does not use the PW-ACH MUST NOT use the BFD CV Types 0x10
> or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers).
> This restriction stems from the fact that the PW-ACH contains a Protocol
> Identification (PID) field, the Channel Type, which is the only way to
> identify BFD messages with these CV types.
> 
> 7. A PW can use the VCCV BFD encapsulation with IP/UDP headers,
> including its concurrent use along with another CV type that uses an
> encapsulation with IP headers (e.g., ICMP Ping or LSP Ping), regardless
> if it is configured to use PW-ACH or not.
> 
> "
> 
> 5. Section 3.3, item (4)
> 
> "
> 
> 4. Only a single BFD CV Type can be selected and used. All BFD CV Types
> are mutually exclusive with the rest, after selecting a BFD CV Type, a
> node MUST NOT use any of the other three BFD CV Types.
> 
> "
> 
> MA> It must be stated that in order to change the negotiation and
> selection of the BFD CV types, the PW must be torn down and re-signaled.

Yes, it is implicit by virtue of inheritance from RFC5085, but I agree
it would help to add it explicitly. We can add it, thanks for bringing
it up.

Thanks,

-- Carlos.

> 
> ---------------------------------------------------
> 
>     ------------------------------------------------------------------------
>     *From:* pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org] *On
>     Behalf Of *BOCCI Matthew
>     *Sent:* Monday, March 09, 2009 11:09 AM
>     *To:* pwe3 <at> ietf.org
>     *Subject:* [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
> 
>     This is the start of working group last call on
>     draft-ietf-pwe3-vccv-bfd-03.txt
> 
>     This draft can be found at:
> 
>     _http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt_
> 
>     The last call will close on Monday 6th April 2009.
> 
>     Please read the document and provide feedback to the PWE3 list.
> 
>     Many thanks to the following, who have also kindly agreed to review
>     the draft and provide comments to the list:
>     Ben Niven-Jenkins
>     Mustapha Aissaoui
>     Luca Martini
>     Yaakov Stein
> 
>     Best regards
> 
>     Matthew
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pwe3 mailing list
> pwe3 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 0 comments |
headers
Carlos Pignataro | 6 May 2009 02:41
X-Face
Picon
Favicon

Re: draft-ietf-pwe3-vccv-bfd-03.txt WG last call

Mustapha,

On 5/5/2009 6:00 PM, AISSAOUI Mustapha wrote:
> All,
> I had a discussion with Peter regarding my comment (1) below and he is
> right that the behaviour I quoted from Section 3.1 of this draft is
> actually supported in the BFD base draft.

Delayed Ack -- thanks again, Peter.

> However, the two directions
> are not completly independent from a state machine perspective. Although
> the session failure detection is always performed by the egress PE in
> the receive direction and it then notifies the ingress PE using the
> Diagnostic Code 1 (Control Detection Time Expired), the egress PE cannot
> transition BFD session back to the UP state unless the ingress PE
> signaled back a Diagnostic code 3 (Neighbor signaled session down) or an
> Init value in the Sta flags. I think it would be useful to add this
> detail in Section 3.1.

I'd be a bit hesitant to keep adding to that description in S3.1, as I
fear it will make it more confusing. Note that the last sentence of that
paragraph also points to pwe3-oam-msg-map for "how it further processes
...", and I think that more detailed description might belong there.

>  
> I appreciate if the authors also updated the terminology for the
> "forward defect"  and "reverse defect" PW states to match the new
> terminology used in draft-ietf-pwe3-oam-msg-map.

OK, there is one instance of "forward defect", and two instances of
"reverse defect" in the document. What should they be changed to?

>  
> My comment on draft-ietf-pwe3-oam-msg-map still holds since there is no
> such a thing as "ingress PE detection of failure" with BFD. Peter
> already updated this in version 10 of the draft. Thanks.

For my clarification, this is already resolved in pwe3-oam-msg-map-10,
correct?

>  
> Also, please ignore my comment (2) regarding the reply mode. Each PE
> encapsulates the BFD packets according to one of the two encapsulation
> methods as per the negotiated CV type. There is no need for sending BFD
> messages out-of-band.

OK.

>  
> I have not seen a response to the other comments below.

Sorry again for the delay, please let me know if there's concerns
unadressed.

Thanks,

-- Carlos.

>  
> Regards,
> Mustapha.
> 
>     ------------------------------------------------------------------------
>     *From:* Busschbach, Peter B (Peter)
>     [mailto:busschbach <at> alcatel-lucent.com]
>     *Sent:* Wednesday, April 08, 2009 3:23 PM
>     *To:* AISSAOUI Mustapha; BOCCI Matthew; pwe3 <at> ietf.org
>     *Subject:* RE: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
> 
>     MA> I do not believe that BFD as defined today supports this mode of
>     operation. This mode requires that each
>     MA> PE be able to declare the PW to be down in the receive direction
>     independently based on not receiving a
>     MA> number of BFD control messages during a number of time
>     intervals. This mode would be similar to the way
>     MA> ATM and Ethernet CC work.
>      
>     Mustapha,
>      
>     I had a different interpretation of the way BFD works. In the
>     asynchornous mode, which the vccv-bfd draft prescribes, each end
>     point checks for the arrival of control messages sent by the remote
>     end. If it does not receive control messages, it enters the DOWN
>     state. This is specified in section 6.2.
>      
>     Since the flow of control messages consists of two independent,
>     uni-directional flows, isn't it true that the downstream PE can
>     autonomously declare a receive defect?
>      
>     Peter
> 
>         ------------------------------------------------------------------------
>         *From:* pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org] *On
>         Behalf Of *AISSAOUI Mustapha
>         *Sent:* Wednesday, April 08, 2009 10:21 AM
>         *To:* Bocci, Matthew (Matthew); pwe3 <at> ietf.org
>         *Subject:* Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
> 
>         Dear all,
>         as requested by Matthew, I reviewed this draft and I have
>         compiled my comments below.
>          
>         Regards,
>         Mustapha.
>         ---------------------------------------------------
> 
>         Comments on draft-ietf-pwe3-vccv-bfd-03
> 
>         1. Section 3.1, last paragraph states:
> 
>         "
> 
>         When the downstream PE (D-PE) does not receive BFD control
>         messages from its upstream peer PE (U-PE) during a certain
>         number of transmission intervals (a number provisioned by the
>         operator as Detect Mult), D-PE declares that the PW in its
>         receive direction is down. In other words, D-PE enters the
>         "forward defect" state for this PW. After this calculated
>         Detection Time, D-PE declares the session Down, and signals this
>         to the remote end via the State (Sta) with Diagnostic code 1
>         (Control Detection Time Expired). In turn, U-PE declares the PW
>         is down in its transmit direction setting the State to Down, and
>         it using Diagnostic code 3 (Neighbor signaled session down) in
>         its control messages to D-PE. U-PE enters the "reverse defect"
>         state for this PW. If needed, how it further processes this
>         error condition, and conveys this status to the attachment
>         circuits is out of the scope of this specification, and is
>         instead defined in [I-D.ietf-pwe3-oam-msg-map].
> 
>         "
> 
>         MA> I do not believe that BFD as defined today supports this
>         mode of operation. This mode requires that each PE be able to
>         declare the PW to be down in the receive direction independently
>         based on not receiving a number of BFD control messages during a
>         number of time intervals. This mode would be similar to the way
>         ATM and Ethernet CC work.
> 
>         However, BFD requires that the sender of the messages declares
>         the state of the PW to be down if replies to its own BFD
>         messages were not received for a number of time intervals.
> 
>         Given that, the sender cannot tell which direction of the PW is
>         down, it must enter the PW receive defect state as explained in
>         draft-ietf-pwe3-oam-msg-map-09.txt. However, the receiver of the
>         messages can send a BFD status change asynchronously and in this
>         case the sender can be sure the defect is in the forward
>         direction, which means it must enter the PW trasmit defect state.
> 
>         I believe Appendix B of draft-ietf-pwe3-oam-msg-map-09.txt must
>         also be corrected as it states:
> 
>         "
> 
>         Furthermore, the detection of a fault could occur at different
>         points in the network and there are several ways the observing
>         PE determines a fault exists:
> 
>         a. egress or ingress PE detection of failure (e.g. BFD)
> 
>         ….
> 
>         "
> 
>         2. Section 3.2 - BFD Encapsulation
> 
>         MA> We need to document how the reply to the BFD packet is
>         encapsulated. The following reply modes of "2- Reply via an
>         IPv4/IPv6 UDP packet", "3 - Reply via an IPv4/IPv6 UDP packet
>         with Router Alert", and "4 - Reply via application level control
>         channel" must be documented for the UDP/IP encapsulation. The
>         PW-ACH necapsulation can only support reply mode 4 since it
>         cannot be routed. I believe the relevant text for this is
>         covered in draft-ietf-bfd-mpls-07.txt.
> 
>         3. Section 3.3, item (3) reads:
> 
>         "
> 
>         4. Pseudowires that do not use a CW or L2SS using the PW
>         Associated Channel Header MUST NOT use the BFD CV Types 0x10 or
>         0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers).
> 
>         A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and
>         L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), and
>         MPLS CC Types 2 and 3 when using a Control Word (as specified in
>         Sections 5.1.2 and 5.1.3 of [RFC5085]). This restriction stems
>         from the fact that the PW-ACH contains a Protocol Identification
>         (PID) field, the Channel Type.
> 
>         B. PWs that do not use a PW-ACH can use the VCCV BFD
>         encapsulation with IP/UDP headers, including its concurrent use
>         along with another CV Type that uses an encapsulation with IP
>         headers (e.g., ICMP Ping or LSP Ping). For example, as specified
>         in Section 7 of [RFC4385], a Pseudowire operating without CW
>         MUST NOT use the PW-ACH.
> 
>         "
> 
>         MA> This paragraph is trying to convey too many things and is
>         confusing. I propose we split it into the case of PW with ACH
>         and PW with no ACH. Here is a proposal which I believe covers
>         all the intended points:
> 
>         "
> 
>         4. A PW that uses the PW-ACH must signal CC Type 1 only in the
>         VCCV parameter included in the interface parameter field of the
>         PW ID FEC TLV or the sub-TLV interface parameter of the
>         Generalized PW ID FEC TLV as described in [RFC 5085].
> 
>         5. A PW that does not use a PW-ACH must signal CC Types 2 and/or
>         3 in the VCCV parameter included in the interface parameter
>         field of the PW ID FEC TLV or the sub-TLV interface parameter of
>         the Generalized PW ID FEC TLV as described in [RFC 5085]. For
>         example, this can be a PW which is configured not to use the CW
>         on the user packets. As specified in Section 7 of [RFC4385],
>         this PW MUST NOT use the PW-ACH.
> 
>         6. A PW that does not use the PW-ACH MUST NOT use the BFD CV
>         Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without
>         IP/UDP headers). This restriction stems from the fact that the
>         PW-ACH contains a Protocol Identification (PID) field, the
>         Channel Type, which is the only way to identify BFD messages
>         with these CV types.
> 
>         7. A PW can use the VCCV BFD encapsulation with IP/UDP headers,
>         including its concurrent use along with another CV type that
>         uses an encapsulation with IP headers (e.g., ICMP Ping or LSP
>         Ping), regardless if it is configured to use PW-ACH or not.
> 
>         "
> 
>         5. Section 3.3, item (4)
> 
>         "
> 
>         4. Only a single BFD CV Type can be selected and used. All BFD
>         CV Types are mutually exclusive with the rest, after selecting a
>         BFD CV Type, a node MUST NOT use any of the other three BFD CV
>         Types.
> 
>         "
> 
>         MA> It must be stated that in order to change the negotiation
>         and selection of the BFD CV types, the PW must be torn down and
>         re-signaled.
> 
>         ---------------------------------------------------
> 
>             ------------------------------------------------------------------------
>             *From:* pwe3-bounces <at> ietf.org [mailto:pwe3-bounces <at> ietf.org]
>             *On Behalf Of *BOCCI Matthew
>             *Sent:* Monday, March 09, 2009 11:09 AM
>             *To:* pwe3 <at> ietf.org
>             *Subject:* [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
> 
>             This is the start of working group last call on
>             draft-ietf-pwe3-vccv-bfd-03.txt
> 
>             This draft can be found at:
> 
>             _http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt_
> 
> 
>             The last call will close on Monday 6th April 2009.
> 
>             Please read the document and provide feedback to the PWE3 list.
> 
>             Many thanks to the following, who have also kindly agreed to
>             review the draft and provide comments to the list:
>             Ben Niven-Jenkins
>             Mustapha Aissaoui
>             Luca Martini
>             Yaakov Stein
> 
>             Best regards
> 
>             Matthew
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pwe3 mailing list
> pwe3 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
Permalink | Reply | 4 comments |
headers
Sherry Xue | 6 May 2009 14:36
Favicon

Re: Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01

Thanks Fred,
Please see inline.

Regards
Sherry
> -----Original Message-----
> From: frederic.jounay <at> orange-ftgroup.com
> [mailto:frederic.jounay <at> orange-ftgroup.com]
> Sent: Tuesday, May 05, 2009 10:03 PM
> To: xueli <at> huawei.com
> Cc: pwe3 <at> ietf.org
> Subject: TR: Re: Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01
> 
> Hi Sherry,
> 
> Thanks for the comments
> Please see my answer inline marked [FJ]
> 
> Regards,
> Fred
> 
> 
> -----Message d'origine-----
> De : Sherry Xue [mailto:xueli <at> huawei.com] Envoyé : samedi 25 avril 2009
09:42
> À : JOUNAY Frederic RD-RESA-LAN Cc : pwe3 <at> ietf.org Objet : Re:Re: Comments
> on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01
> 
> Hi, Fred,
> I totally agree with your opinion that the leaf-initiated mode and
> source-initiated mode are not restricted in the application of SS-PW and
MS-PW.
> IMO, leaf initiated mode is more conveniently for MS-PW, and in the source
> initiated mode, more work should be considered for MS-PW, such as AD and
PW
> routing. I agree the standardization work course with admiration.
> [FJ] Yes, it's true, we probably need both setup modes depending on SP
> requirements. That's why we tried to define a new multicast FEC element
which
> could fit to both.
> 
> For P2MP SS-PW setup in leaf-initiated mode, it may be divided into two
> instances:
> [FJ] I think you mean P2MP MS-PW?

[SX] In this case, I mean P2MP SS-PW exactly. In Leaf-initiated mode, P2MP
MS-PW setup procedure had been described correctly, and P2MP SS-PW should be
considered also IMO.
That it to say, there is no S-PE between the source PE and the leaf-PEs.
AND, the leaf-PEs initiate the P2MP SS-PW setup.

> 1)over P2P PSN :
> this case may be according to MP2P signaling, similarly as
> star-topology(logically), in which P2MP SS-PW is composed of m(leaf
no.)*P2P
> SS-PW, and all the P2P SS-PWs should be setup individually without
> consideration of the merge-node(physically). That is to say in the merge
node,
> there will be different labels allocated upstream for different downstream
> T-PEs.
> [FJ] In that case the downstream Label assignment should be considered, is
it
> what you mean?

[SX]yes, as pre-described, In leaf-initiated mode, the downstream label
assignment should be considered. Each leaf-PE should assignment PW label to
source.

> 2) over P2MP PSN
> The merge-node should record the Label(called label L) allocated by the
> downstream TAII(called  X) with SAII( S ), and if another signaling
message
> from other TAII(i.e.,Y) is received with same SAII, the merge-node should
> allocated label L for TAII Y(upstream label assignment), and then allocate
> upstream label to next upstream hop.
> IMO, if the P2MP PW is initiated by the leafs, the PSN tunnel should be
restrict
> to P2P, because it sounds illogical that the leaf node is used to manage a
P2MP
> LSP or PW? What about your opinion?
> [FJ] I think if we consider PW segments over P2MP LSP, we must consider
only
> the upstream Label assignment. Because in your first step you derscribe,
the
> dowstream Label assigned by the first Leaf could be already in use by
another
> P2MP PW.

[SX] Correctly,in the case of PW segments over P2MP LSP, I appreciate if the
label assignment should be restricted in upstream assignment. 

> [FJ]I've the feeling we may have the requirement to define P2MP MS-PW/P2MP
LSP,
> and this would require Leaf PE to request the upstream PW P2MP Label for
this
> segment. We need more feedbazck on it from the WG

[SX] I agree. P2MP MS-PW over P2MP LSP should be defined. And MAY the case
be that the P2MP MS-PW is coincident with the P2MP LSP. Other cases, such
as, LSPs which carry P2MP MS-PW is composed by more than one P2MP LSP and/or
P2P LSP may not be required, only complex and confusion.

> For P2MP MS-PW setup in source-initiated mode, the explicit routing should
be
> provided in the source PE. So the LDP should be extended for MS-PW setup
> according explicit routing. Right? Whether the explicit routing is the
only
> method for the PW routing?
> [FJ] the explicit routing mode is not mandatory for the source-initiated
> solution.

[SX] If the explicit routing is not mandatory, the dynamic routing should be
considered? Such as some multicast routing protocol?

> Regarding the P2P PW setup procedure, there are two protocols, LDP and
BGP.
> Could we use BGP for P2MP PW setup?
> [FJ] Rahul has proposed an ID for P2MP PW setup based on BGP, derived from
the
> VPLS multicast solution. Based on existing deployment around L2VPN, the SP
may
> need to both solutions (LDP, and BGP)
> http://www.potaroo.net/ietf/idref/draft-raggarwa-l2vpn-p2mp-pw/

[SX] thanks Fred for informing about the draft.
> 
> 
> Best wishes and regards
> Sherry
> 
>
Permalink | Reply | 1 comment |

Gmane