Subject: RE: Re: I-D ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt

From: David McDysan <[email-masked]>
Date: Wed, 19 Jan 2005 11:28:41 -0500

A few comments in line. Other material snipped.

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luca Martini
> Sent: Tuesday, December 14, 2004 5:52 PM
> To: Sasha Vainshtein
> ACTION:draft-martini-pwe3-MH-PW-requirements-00.txt
> 

> 
> >    1. I think that the following statement in the "Use 
> Cases" section
> >       requires clarification: "*At a minimum PW control
> >       channel establishment requires knowledge of and 
> reachability to
> >       the remote (ultimate) PE IP address*". I understand that
> >       *reachability* of the remote ultuimate PE IP address may be
> >       problematic in some cases; but do we really envision the case
> >       when a PE can be set up without the one of the ultimate PEs
> >       possessing any *knowledge* about IP address of its 
> remote peer?
> >       And, if this is the case, can in-band OAM provide end-to-end
> >       connectivity verification?
> >
> sure. you can use 127.0.0.1 as the IP address of the in-band 
> OAM packets . I think that the requirement is to be able to 
> establish a MH-PW between 
> 2 U-PEs with out having complete knowledge of each other's IP 
> addresses. 
> This does not mean that some S-PE in the middle does not know 
> about at 
> least one of the U-PE IP addresses.
> Most of the text following is more a justification for the 
> requirement.

The above discussion implies that there is a need to make known (e.g.,
advertise in some way) the U-PE addresses (or address prefixes) reachable by
an S-PE. Should this be worded as a requirement in the routing section?

> 
> >    1. What exactly is meant by "tunneled MH-PWs" and 
> "overlay tunnels"
> >       (in item ii of Section 6.1)? These notions are not defined
> >       anywhere (AFAIK)
> >
> I think that this means that if PW are used to build a PSN, 
> then if the 
> PSN is in turn used to carry PWs, the latter should not be 
> impacted by 
> the former PWs.
> ( quite frankly I cannot see how they could ... )
> 

This confused me as well. Please either clarify or delete.

> >    1. Change of encapsulation mode defined as an option for 
>  S-PEs is
> >       not defined unambiguously. E.g., suppose that I want 
> to carry an
> >       ATM VC bewteen two CEs: can an S-PE change encapsulation from
> >       "N-to-one" to "One-to-one"? Or from Cell relay to 
> SPDU? (In case
> >       anybody has his/ger doubts, I find this ptoposal 
> abhorrent, but
> >       it is not explicitly prohibited by the text as I read it)
> >
> yes. Actually I would like to ask the SPs , if they really want to 
> operate a network that might have an Interworking function somewhere 
> along it path?  To me this is operational suicide. After all 
> a PW could 
> be interworked several times .. like ethernet -> ATM ->Frame-Relay -> 
> Ethernet ....
> Interworking at the S-PE  is one of the requirements that I 
> would like 
> to seriously consider removing.

Fig 2 shows "optional PW adaptation function." Provisioning to and providing
dynamic discovery and restoration of interworking points has been a
challenging problem in the past. There is very little text in the document
on requirements for this function, and if it is to be included much more
would need to be added. Another issue could be selection of a particular
domain where the interworking could be performed. For example, in a MH-PW
with three PW-segments (i.e., SH-PW) each could have an S-PE that could
perform interworking. How is one S-PE specified? If that one S-PE fails, how
is an alternate selected? Suggest that this be removed from this document
and handled separately. I wonder if the subject of interworking would better
be handled in L2VPN instead of PWE3.

> 
> >    1. Item i in Section 6.2 requires that U-PEs and S-PE are capable
> >       of admission control per PSN tunnel. Does this preclude PSN
> >       tunnels that do not have any explicit QoS guarantees (like
> >       L2TPv3)? Or does it mean that, for these ctunnels, admission
> >       control simply admits everything? (I'm pretty sure 
> that at least
> >       one of you will attribute this comment one more incaration of
> >       the original PWE3 sin, namely, that MPLS = IP, but then, at
> >       least one other participant of this team has explicitly
> >       requested L2TPv3 becoming as standard as MPLS for PWs ;-)
> >
> This is not an unreasonable question. L2TPv3 might have 
> several session 
> each with different QoS settings in the DSCP bits of the IP header. 
> Tunnel CAC need not be based on RSVP-TE. I believe that the 
> intent was 
> to mention only MPLS LSPs.
> However I would like to hear from Lei how can CAC be used in 
> l2TPv3. ( also this section has spell errors and grammar 
> issues ... ) We also need to consider that TE is 
> unidirectional , but PW are 
> bi-directional.  what happens if a PW is admitted in one 
> direction , but 
> fails in the other direction ?
> 

There is also the issue of alternate routing that I did not see discussed in
the draft. For example, if a first choice S-PE is selected (in some manner)
and admission control fails for the (locally selected?) "next-hop" PSN
tunnel toward the U-PE, is there a requirement for the MH-PW to attempt to
use some other S-PE?

> >    1. Item ii in Section 6.2 seems even more suspicious because it
> >       requires that U-PEs and S-PEs actually select a path 
> across the
> >       PSN along which the traffic will be tunneled. IMHO we 
> have nvere
> >       before discussed this "requirement"; can somebdy 
> please point to
> >       its origin?
> >
> I think this is needs to be re-written to fit into the pwe3 charter :
> 
> When setting up a MH-PW, S-PEs and U-PEs MUST be able to request a 
> tunnel across the PSN in such a way as to  satisfy the MH-PW QoS and 
> bandwidth requirements. Restrictions may apply depending on 
> the method 
> used for setting up a PW segment and on PSN  tunnel types.
> Note that this is not new, and can be achieved today in many SH-PW 
> implementations.
> 

I suggest that more requirements are needed in 6.4 on Routing to specify
MH-PW path selection.

> Luca
> >                                   Sasha Vainshtein

---

From: David McDysan <[email-masked]>
Date: Wed, 19 Jan 2005 12:49:17 -0500

Some additional comments on draft-martini-pwe3-MH-PW-requirements-00.txt not
covered in previous posts.

Dave

Section 5 Use cases, iv, PWs in Metro networks

Suggest adding a sentence stating that the topology that connects a U-PE
access metro device to an S-PE metro aggregation may be simple (e.g., single
homed from a packet routing perspective) and that restoration may be handled
at lower layers (e.g., SONET/SDH protection).

Section 6.2 Traffic Engineering

Suggest stating the full set of TE parameters: capacity (at least average
rate, possibly peak rate), burst duration (token bucket depth). Has the use
of affinities (i.e., colors) been considered to support the diversity
requirement in section 6.4, routing? 

Section 6.3 QoS

This discussion needs to be converted into requirements language. Two
requirements I read out of this are:
	1) Mandatory request for QoS - if this cannot be met, then the MH-PW
attempt is rejected
	2) Desirable request for QoS - if this cannot be met, then another
QoS characteristic can be provided. Suggest that in this case notification
indicate the type of QoS that was provided. This would in general need to be
a list if a number of domains are traversed.

Of course, need to more precisely define what is meant by QoS and what
standard convention would be used to communicate it.

Fourth paragraph: Need more descriptive text on BW broker. Is there a
reference to this concept that provides defines the concept and the proposed
protocols? How would the BW broker interact with routing? 
 
6.4 Routing

Suggest adding a mandatory (SHALL) requirement where the sequence of S-PEs
is explicitly specified. 

There are at least two ways of implementing this; via an object in the PW
signaling message, or OSS provisioning of the intermediate S-PEs with the
S-PE next hop using (part of) the generic FEC, possibly AGI to identify this
explicit route. 

This explicit routing specification of S-PEs does not meet all resiliency
scenarios, but would be useful in scenarios where topology and alternate
routes are limited (e.g., a metro access network).

As mentioned in earlier posts, the general problem of designing another
level of S-PE routing is not trivial and a simple solution that meets a
simpler network environment as a subset of the full solution is desirable. 

6.6 OAM

 -v. MH-PW OAM SHOULD support switch over between 1+1 protected
            LSPs end-to-end.

I don't understand this one. Does LSP refer to a PSN tunnel in a single
domain? Please elaborate.